Cómo validar las habilidades técnicas de un desarrollador remoto
ProLatamWork Editorial •
2024-12-27 •
8 min de lectura
Métodos efectivos para asegurar que el candidato sabe lo que dice saber antes de contratarlo.
Un developer que miente en su CV o que exagera su nivel técnico puede costarle a una startup decenas de miles de dólares en trabajo reecho, deadlines perdidos y código que nadie más puede mantener. El problema no es que sea difícil evaluar habilidades técnicas — es que muchas empresas no tienen un proceso definido. Este es el proceso que funciona.
Por qué el CV y el portfolio solo cuentan la mitad de la historia
Un CV dice "5 años de experiencia en React". Eso puede significar cosas muy distintas: puede ser alguien que construyó 3 productos complejos en producción, o alguien que pasó 5 años manteniendo un proyecto legacy de 2014 sin aprender nada nuevo. El portfolio de proyectos es mejor señal — pero también puede estar inflado: el proyecto puede ser de un tutorial, puede haber sido trabajo de otro, puede no representar su nivel actual.
La validación real requiere interacción directa con el candidato. El objetivo no es atrapar mentiras — es entender el nivel real para ver si encaja con lo que necesitas.
Paso 1: Revisión del portfolio con preguntas específicas
No revises el portfolio en silencio — revísalo con el candidato en la misma llamada. Pide que te explique:
¿Cuál fue el desafío técnico más complejo de este proyecto? ¿Cómo lo resolviste?
¿Qué cambiarías hoy si lo construyeras de nuevo?
¿Qué parte de este código te da más orgullo? ¿Por qué?
¿Cuál fue el tradeoff más difícil que tuviste que tomar?
Un developer que realmente hizo el trabajo puede responder estas preguntas con naturalidad y con detalles específicos. Uno que no lo hizo se queda en generalidades o en respuestas que suenan a plantilla.
Señales positivas en el portfolio
Repositorio público en GitHub con historial de commits que muestra trabajo progresivo
README bien documentado que explica arquitectura y decisiones
Issues y pull requests cerrados — señal de trabajo colaborativo real
Proyectos en producción con usuarios reales (aunque sean pocos)
Señales de alerta
Solo proyectos de tutoriales clonados (To-do app, blog clone, weather app)
Commits todos en el mismo día o en fechas muy juntas — probablemente subido para el proceso
No puede explicar decisiones de arquitectura o por qué eligió ciertas tecnologías
Portfolio perfecto pero no puede mostrar código real que haya escrito recientemente
Paso 2: Entrevista técnica conversacional (no de trivia)
Las preguntas de trivia ("¿qué es el event loop en JavaScript?") son fáciles de memorizar y no predicen performance en el trabajo real. Las preguntas de razonamiento son mucho mejores señal.
Preguntas de razonamiento que funcionan
Sobre decisiones técnicas:
"Describe una decisión de arquitectura que tomaste en un proyecto pasado. ¿Cuál fue el tradeoff? Si lo hicieras de nuevo, ¿cambiarías algo?"
"¿Cuándo usarías SQL y cuándo NoSQL? Dame un ejemplo de proyecto real donde hayas tomado esa decisión."
Sobre resolución de problemas:
"Cuéntame de un bug difícil que te tomó más tiempo del esperado resolver. ¿Cómo lo encontraste?"
"¿Cuál fue el proyecto más técnicamente desafiante en el que trabajaste? ¿Qué lo hacía difícil?"
Sobre trabajo en equipo:
"¿Cómo manejas el feedback de code review cuando no estás de acuerdo con el comentario?"
"Dame un ejemplo de cuando un desarrollador con quien trabajaste tenía un enfoque muy diferente al tuyo. ¿Cómo lo resolvieron?"
Escucha si el candidato habla de tradeoffs, si reconoce limitaciones en sus decisiones pasadas, si puede explicar cosas complejas con claridad. Esas son señales de un desarrollador maduro.
Paso 3: Prueba técnica práctica
La prueba técnica es el momento de validación más directo. Reglas para hacerla bien:
Diseño de la prueba
Relevancia: Debe parecerse al trabajo real que hará. Si van a construir features de backend en Node.js, la prueba debe ser de backend en Node.js — no de algoritmos de ordenamiento.
Tamaño razonable: 2-4 horas máximo. Una prueba que toma 8 horas filtra candidatos buenos que tienen trabajo y vida — no filtra candidatos malos.
Criterios claros: Explícitamente cuéntale qué evaluarás: funcionalidad, estructura del código, manejo de errores, tests.
Pago si es larga: Si la prueba toma más de 2 horas, págala. Es trabajo real. Los candidatos serios lo valoran y los mediocres no se molestan.
Qué evaluar más allá de "funciona"
Legibilidad: ¿El código es fácil de entender? ¿Los nombres de variables y funciones son claros?
Estructura: ¿Hay separación de responsabilidades? ¿Está organizado de forma lógica?
Manejo de errores: ¿Considera los casos edge? ¿Qué pasa si el input es incorrecto?
Tests: ¿Escribió tests? ¿Los tests son útiles o son solo para cumplir?
Explicación: ¿Explicó sus decisiones en el README o en comentarios? ¿Reconoció lo que no alcanzó a hacer?
Un desarrollador que entrega código que funciona, está bien estructurado, tiene algunos tests y un README que explica sus decisiones — aunque no sea perfecto — es un mejor candidato que uno que entrega código que funciona pero que nadie más puede entender.
Paso 4: Verificación de referencias
Las referencias son el paso más saltado y también uno de los más valiosos. Una llamada de 15 minutos con un cliente o manager anterior te da información que ninguna entrevista puede darte.
Preguntas que dan información real:
"¿Lo volverías a contratar? Si sí, ¿para qué tipo de proyecto? Si no, ¿por qué?" — La hesitación en esta respuesta dice mucho.
"¿Cómo se comunicaba cuando había un problema o un retraso?"
"¿Cuál era su mayor fortaleza técnica? ¿Y su mayor área de mejora?"
"¿Hubo alguna situación difícil? ¿Cómo la manejó?"
En plataformas como ProLatamWork, las calificaciones y reseñas de proyectos anteriores cumplen parcialmente esta función — puedes ver el historial de proyectos completados y los comentarios de clientes reales.
Paso 5: Proyecto piloto pagado (el mejor filtro)
Para proyectos de larga duración o posiciones críticas, nada valida mejor que un proyecto piloto real de 1-2 semanas. Pagas por el trabajo (es trabajo real), obtienes algo útil y al mismo tiempo evalúas:
Calidad técnica real en tu codebase específico
Comunicación durante el trabajo — no solo en una entrevista
Cumplimiento de plazos en condiciones reales
Fit cultural con el equipo
Capacidad de hacer preguntas correctas y apropiadas
Un developer que pasa el piloto bien casi nunca decepciona en el proyecto completo. Es el proceso de validación más caro (pagas por el tiempo) y el más confiable.
El proceso completo resumido
Revisión de portfolio con preguntas en vivo (30 min) — filtra candidatos que no pueden explicar su propio trabajo
Entrevista técnica conversacional (45-60 min) — evalúa razonamiento, no memorización
Prueba técnica relevante y pagada (2-4h) — valida habilidades en contexto similar al trabajo real
Verificación de referencias (1-2 llamadas de 15 min) — información que ninguna entrevista da
Proyecto piloto pagado opcional (1-2 semanas) — para roles críticos o de larga duración
El proceso completo puede tomar 1-2 semanas. Vale la pena: una contratación incorrecta en desarrollo puede costarte el triple en trabajo reecho, gestión extra y tiempo perdido. Un proceso de validación bueno es la inversión de menor costo con el mayor retorno que existe en contratación técnica.
