Contratar por habilidades de software: una prueba práctica en vez de buscar palabras clave en el CV

TL;DR

La experiencia declarada en un CV no demuestra dominio operativo. Una prueba breve, basada en una tarea real y evaluada con una rúbrica definida antes de entrevistar, revela qué sabe hacer la persona y qué puede aprender.

• Competencia de software que el puesto necesita → Define tareas críticas.
• Matriz rol-herramienta → Separa uso y disciplina.
• Prueba práctica de 20 minutos → Simula el trabajo real.
• Rúbrica escrita antes de entrevistar → Puntúa evidencia observable y fija un umbral.
• Evaluación consistente y contraste con el CV → Contrasta CV y ejecución.
• Decidir entre contratar, formar o descartar → Distingue riesgo y formación.
• Reutilizar la matriz para desarrollo interno → Sirve para formar, mover y promover talento.

Takeaway: Contrata por comportamientos observables, no por una lista de nombres de software. La misma evaluación puede servir después para formar, mover y promover talento.

Competencia de software que el puesto necesita

Un CV puede decir “manejo avanzado de CRM”, “dominio de Excel” o “experiencia con ERP”, pero no aclara si la persona puede registrar una oportunidad sin duplicarla, interpretar un reporte o corregir un error sin alterar datos históricos. Primero define qué trabajo debe ejecutar y después qué parte debe probar.

Empieza con tres a seis tareas frecuentes y de alto impacto, tomadas de la operación diaria del puesto. Para una persona ejecutiva de ventas, podrían ser:

• Registrar una oportunidad con etapa, monto, fecha estimada y responsable.
• Actualizar el siguiente paso después de una llamada.
• Filtrar el pipeline por territorio y periodo.
• Exportar una lista de seguimiento sin modificar los registros originales.

En un rol administrativo, las tareas serían distintas: cargar facturas, validar campos obligatorios, localizar una orden de compra y resolver una discrepancia básica. El software aparece después. La pregunta no es si conoce Salesforce, SAP o Excel, sino si puede ejecutar una parte del proceso con precisión y sin supervisión constante.

Para cada tarea, describe el nivel esperado:

El criterio no debería ser “que conozca la interfaz” en abstracto. Debe demostrar lo que causaría un error costoso o bloquearía a otro equipo. La navegación y la ubicación de menús pueden aprenderse durante el onboarding; la atención al detalle, el seguimiento de pasos y la verificación del resultado son más difíciles de desarrollar desde cero.

Una buena definición produce una frase concreta: “Puede crear un registro, completar los campos obligatorios, revisar el resultado y dejar trazabilidad del siguiente paso”. Esa frase sirve para diseñar la prueba, entrevistar y decidir qué debe ser imprescindible y qué puede desarrollarse después.

Kit de pruebas de habilidades: rúbrica y ejercicios

Ingresa tu correo electrónico para descargar una guía que te ayudará a comenzar con cualquier software de gestión de proyectos.

Reconozco que he leído y entendido la Política de Privacidad de Bitrix24

Matriz rol-herramienta

La matriz rol-herramienta conecta cada tarea con el software que la soporta y con la capacidad que debe observarse. No es un inventario de licencias ni una lista de cursos, sino un mapa de ejecución.

Cada fila debería indicar la tarea, la herramienta, el tipo de capacidad, la conducta observable, el nivel esperado y el criterio de contratación.

Separa dos tipos de dominio. La habilidad de interfaz incluye encontrar funciones, aplicar filtros, cambiar vistas y completar pantallas. Una persona con experiencia en sistemas parecidos puede aprender estas acciones aunque no conozca los botones exactos.

En selección de talento, por ejemplo, un CRM puede reunir funciones para organizar candidatos, hacer seguimiento y mantener la información del proceso en un mismo lugar. Entre las funcionalidades de un CRM para cazatalentos están el seguimiento de candidatos, la gestión de etapas y el registro del historial de comunicación, capacidades que pueden trasladarse a la matriz.

En Bitrix24, por ejemplo, la prueba debería centrarse en actualizar registros, cambiar estados y registrar el siguiente paso, no en recordar dónde está cada función.

La disciplina de datos comprende introducir información con precisión, usar campos de forma consistente, no sobrescribir valores sin revisar, conservar el formato acordado y seguir el proceso. Afecta reportes, facturación, pronósticos y el trabajo de otros equipos.

Alguien puede aprender dónde está el botón para importar datos, pero si no revisa duplicados, no confirma el archivo correcto o no entiende qué registros modifica, la destreza de interfaz no compensa el riesgo. Por eso la matriz debe separar “uso del sistema” y “calidad de la operación”.

Clasifica cada capacidad según su impacto:

• Imprescindible al contratar: un fallo compromete clientes, ingresos, cumplimiento o continuidad del proceso.
• Evaluable con una prueba corta: puede observarse en una tarea simulada de pocos minutos.
• Desarrollable internamente: requiere conocer la configuración propia, pero no una base técnica nueva.

Así puedes reconocer habilidades transferibles sin pedir experiencia exacta con todas las herramientas de la empresa. El candidato quizá no haya usado el mismo CRM, pero puede demostrar que entiende registros, estados, filtros y validaciones.

Prueba práctica de 20 minutos

La prueba debe parecerse a un fragmento real del puesto, no a una competencia de memoria sobre menús. Elige una situación breve con instrucciones, datos y resultado esperado: “Una oportunidad pasó de evaluación a propuesta. Actualiza el registro, agrega el siguiente paso y prepara una vista con las oportunidades que requieren seguimiento esta semana”.

Este enfoque no es ajeno a la contratación basada en habilidades. Según el informe State of Skills-Based Hiring 2024, el 81% de los empleadores encuestados ya utilizaba algún método de contratación basado en habilidades, frente al 56 % en 2022. Dentro de esas prácticas, el 38% utilizaba ejercicios de muestra de trabajo (work sample assignments), que permiten observar cómo una persona ejecuta tareas relacionadas con el puesto.

El escenario puede resolverse en cuatro acciones:

1. Localizar y revisar: encontrar el registro correcto y comprobar la información existente.
2. Ejecutar: actualizar los campos indicados sin modificar datos ajenos.
3. Verificar: confirmar que estado, fecha y siguiente paso quedaron correctos.
4. Presentar: mostrar el resultado o explicar qué haría con una excepción.

No agregues pasos para llenar los veinte minutos. Las instrucciones deben explicar el objetivo sin describir cada clic, de modo que puedas observar cómo revisa antes de actuar y cómo decide.

Entrega un conjunto de datos ficticio con elementos normales y una excepción controlada: un registro duplicado, una fecha inconsistente o un campo obligatorio vacío. La excepción permite observar si la persona se detiene, pregunta, documenta el problema o sigue avanzando.

El mismo enfoque puede trasladarse a otros sistemas. En un ERP, por ejemplo, la tarea puede consistir en cargar una factura, validar los campos obligatorios y detectar una discrepancia con la orden de compra. Lo que se evalúa sigue siendo la revisión, la ejecución, la verificación y la gestión de excepciones, no el conocimiento de una interfaz concreta.

Si el sistema real contiene información sensible o es demasiado complejo, usa una versión demo, capturas navegables, una hoja preparada o una simulación guiada. Trabaja con datos sintéticos y, cuando sea posible, cuentas sandbox y registro de auditoría. Si la prueba requiere acceso a información real, limita los permisos al mínimo necesario y establece previamente las condiciones de confidencialidad.

Antes de la sesión, valida la tarea con alguien que desempeñe el puesto. Debe resolverla, detectar instrucciones ambiguas y confirmar el resultado esperado, los campos que no deben tocarse y los errores de riesgo.

Durante la ejecución, el evaluador interviene lo mínimo y registra decisiones y preguntas. “¿Puedo cambiar este valor?” muestra una cautela distinta de “lo dejo así porque seguramente no importa”.

En una prueba sobre Bitrix24, por ejemplo, interesa observar cómo la persona actualiza una oportunidad, registra el siguiente paso y comprueba que el cambio quedó correctamente reflejado.

"El logro más destacado ha sido maximizar la eficiencia de los procesos de análisis de créditos y de cobranzas."

Jefe de Ventas externas, Gustavo Domínguez

IMAG S.R.L.

EMPEZAR GRATIS

Rúbrica escrita antes de entrevistar

Redacta la rúbrica antes de ver candidatos. De lo contrario, el evaluador puede premiar la familiaridad con una marca o justificar a quien le cayó bien. La rúbrica convierte impresiones en evidencia comparable.

Para cada acción define desempeño fuerte, aceptable y débil:

Mantén separados velocidad razonable, exactitud, manejo de errores y disciplina de datos. Terminar rápido no demuestra competencia fiable: una persona que verifica su trabajo puede aportar más evidencia que alguien que navega con soltura y deja registros incompletos.

Establece un umbral antes de evaluar. Por ejemplo, puedes exigir 70 sobre 100, siempre que no exista ningún knockout. El porcentaje debe adaptarse al riesgo del puesto: una función que maneja datos financieros o información sensible puede requerir un umbral superior.

Define también las señales de descarte antes de empezar:

• Inventar información para completar un campo.
• Borrar o sobrescribir datos sin revisar.
• Ignorar una instrucción de seguridad o confidencialidad.
• Ocultar un error o no informar de un resultado incierto.
• Modificar información fuera del alcance indicado de forma consciente.

Un clic equivocado que se detecta y corrige muestra un comportamiento distinto de alterar registros y minimizarlo. El knockout debe aplicarse por la conducta observada, no por la falta de familiaridad con una herramienta concreta.

También registra señales de aprendizaje rápido: preguntas específicas, razonamiento explícito, reconocimiento de limitaciones, transferencia de una lógica conocida a una interfaz nueva y corrección ante un error. Así distingues una brecha de navegación de una falta de método.

Evaluación consistente y contraste con el CV

Usa el CV para formular hipótesis, no para cerrar la evaluación. “Administró el CRM” puede significar que creó registros a diario, consultó reportes o acompañó una implementación. La prueba aclara cuál de esas experiencias existió.

Explica a todos los candidatos el mismo objetivo, tiempo, datos de entrada y resultado esperado. Usa el mismo entorno y pauta de observación. Mantener una experiencia clara y consistente ayuda a que la evaluación se centre en la ejecución y no en diferencias en la forma de entrevistar.

El evaluador puede registrar:

• Qué revisó antes de empezar y qué acciones ejecutó.
• Qué preguntas hizo y qué errores detectó o dejó pasar.
• Cómo verificó el resultado final.

Puedes usar un guion fijo para iniciar la prueba: “Tienes 20 minutos para completar esta tarea con los datos proporcionados. El resultado esperado es [resultado]. Puedes hacer preguntas si encuentras una ambigüedad, pero no recibirás indicaciones sobre qué función utilizar. Al terminar, explica brevemente qué has comprobado.”

La entrevista no debe convertirse en una clase. Si pregunta dónde está una función, permite que explore, pero no señales el botón. Si una instrucción resulta ambigua, registra la aclaración dada para mantener un trato equivalente.

Para el evaluador, una checklist sencilla ayuda a mantener el foco:

• Revisó los datos antes de modificarlos.
• Siguió el procedimiento sin alterar información fuera del alcance.
• Detectó la excepción o el error disponible.
• Verificó el resultado antes de terminar.
• Documentó o comunicó cualquier incertidumbre relevante.

Aplica la misma estructura de evaluación a todas las personas, pero permite adaptaciones razonables cuando sean necesarias para que una discapacidad u otra necesidad de accesibilidad no afecte a la prueba de una capacidad que el puesto realmente requiere. Mantén constantes el objetivo y los criterios, aunque puedan variar el tiempo, la modalidad remota o la forma de interacción.

Después, haz preguntas de contexto sin repetir la tarea:

• ¿Con qué frecuencia realizabas esta operación?
• ¿Qué campos o pasos eran obligatorios en tu equipo?
• ¿Qué ocurría al encontrar un duplicado o un dato incorrecto?
• ¿Quién revisaba los resultados y cómo se documentaron los cambios?

Conecta las respuestas con lo observado. Alguien puede ejecutar bien una carga sin haber sido responsable de revisar su calidad posterior. Del mismo modo, quien no reconoce la interfaz puede explicar una experiencia sólida al proteger versiones, validar entradas y escalar excepciones.

Registra puntuación y notas por separado: la primera facilita la comparación y las segundas conservan el contexto.

Decidir entre contratar, formar o descartar

Lee los resultados por bloques, no solo por una calificación total. Una suma puede ocultar un riesgo serio, como una buena navegación con mala calidad de datos. Separa estas preguntas:

• ¿Puede operar sin poner en riesgo el proceso? Evalúa exactitud, seguimiento de pasos y manejo de información sensible.
• ¿Qué parte necesita aprender? Puede ser la configuración propia, nombres internos, atajos o reportes específicos.
• ¿El equipo puede formar esa brecha? Una habilidad enseñable deja de serlo si el puesto exige autonomía inmediata y no hay acompañamiento.

Contrata cuando cumple los prerrequisitos de disciplina y criterio, aunque necesite aprender la interfaz de la empresa. Forma cuando la brecha está en navegación, velocidad o funciones específicas, pero mantiene un método confiable. Descarta cuando compromete consistencia, trazabilidad o control de datos, especialmente si no detecta el problema o lo minimiza.

Algunos casos ayudan a aplicar el criterio:

• Contratar: ejecuta correctamente la tarea, detecta un duplicado y explica cómo resolverlo, pero necesita aprender determinadas funciones del CRM.
• Formar: comete un error menor de formato, acepta la corrección y demuestra un método consistente.
• Descartar: modifica registros fuera del alcance, ignora una excepción o no informa de un error que afecta a otros datos.

Traduce la decisión en una brecha concreta. “Necesita capacitación en el CRM” dice poco; “puede actualizar registros y validar campos, pero necesita aprender vistas, permisos y el flujo de escalamiento” permite organizar el onboarding. También puedes apoyarte en herramientas de IA aplicadas a recursos humanos para organizar información y detectar patrones de habilidades, siempre manteniendo la evaluación basada en evidencias observables.

Para una brecha desarrollable, estructura las dos primeras semanas alrededor de lo observado:

• Semana 1: aprender la configuración, los nombres internos y los flujos propios.
• Semana 2: repetir las tareas críticas con supervisión decreciente y comprobar los mismos criterios de la prueba inicial.

Si la brecha era de navegación, el plan debe centrarse en el uso del sistema; si era de disciplina de datos, necesita más práctica supervisada y revisión de resultados.

Evalúa también la prueba. Si casi todos fallan en una acción que el puesto rara vez exige, está mal enfocada. Si las puntuaciones son altas pero los nuevos ingresos cometen errores frecuentes, la rúbrica no mide el riesgo correcto.

Modifica la matriz cuando cambie el trabajo o la evidencia muestre que el instrumento no predice desempeño; no la ajustes para favorecer a un candidato.

Reutilizar la matriz para desarrollo interno

La matriz no debería desaparecer después de cubrir la vacante. Sirve para revisar qué sabe hacer el equipo y qué capacidades necesita desarrollar para asumir más responsabilidad.

Usa las mismas filas en una evaluación interna. No siempre hace falta repetir la prueba formal: un líder puede observar una operación real, revisar una muestra de registros o pedir una simulación cuando el proceso sea sensible. Las capacidades ya están definidas: usar, analizar, mantener calidad o resolver una incidencia.

Las brechas pueden agruparse así:

• Por herramienta: varias personas necesitan aprender funciones de un sistema específico.
• Por proceso: el problema está en el flujo entre ventas, operaciones, finanzas o soporte.
• Por disciplina de datos: hay inconsistencias en nombres, campos obligatorios, versiones o trazabilidad.

Cada grupo requiere una respuesta distinta. Un taller de navegación puede resolver la primera. La segunda suele requerir ejemplos del proceso completo, responsables definidos y práctica con excepciones. La tercera exige criterios comunes, revisión de muestras y retroalimentación sobre registros reales. Contar con herramientas de retroalimentación puede ayudar a convertir estas observaciones en un seguimiento más continuo. Otro curso de software no corrige una regla de captura mal entendida.

La matriz también ayuda en la movilidad y promoción. Para pasar de analista a coordinador quizá no se necesite otra plataforma, sino interpretar resultados, revisar el trabajo de otras personas y resolver incidencias básicas. Identificar estas capacidades antes de que aparezca una vacante puede contribuir a crear recorridos de desarrollo y retener talento dentro de la empresa.

Asigna a una persona responsable de mantenerla y revísala al menos cada seis meses; en roles donde los procesos cambian con frecuencia, puede tener sentido hacerlo cada trimestre. Conecta las brechas detectadas con las evaluaciones de desempeño y con planes concretos de formación o movilidad.

En Bitrix24, por ejemplo, la misma matriz puede servir para identificar qué capacidades necesita reforzar un equipo antes de asignarle nuevos flujos o responsabilidades.

Así se convierte en un recurso común para contratar, organizar el onboarding y desarrollar talento. La herramienta puede cambiar; la lógica de observar tareas, método y calidad de datos sigue siendo útil.