---

---

Cómo detectar la experiencia en una sola entrevista

En la industria tecnológica actual, es raro encontrar una entrevista técnica en la que alguien no mencione Kubernetes, serverless, inteligencia artificial o algún framework recién lanzado la semana pasada. Los CVs se llenan de logos de herramientas como si fueran medallas olímpicas. Pero cuando se trata de resolver un problema real —uno que impacta en ingresos, en usuarios o en la operación diaria de un negocio—, sorprende cuántos supuestos expertos tropiezan antes de dar el primer paso.

¿Por qué? Porque confunden conocimiento técnico con experiencia real.

La experiencia no se mide por cuántas tecnologías has usado, sino por cuántas veces has resistido la tentación de usarlas sin necesidad. El verdadero profesional no entra a una reunión con la solución ya armada en la cabeza. Entra con preguntas. Muchas preguntas.

Imagina esta escena: estás en una entrevista y planteas un requerimiento funcional sencillo. Podría ser algo como “necesitamos un sistema para gestionar órdenes de servicio en terreno”. Hay quien, sin siquiera entender el contexto del negocio, el volumen de operaciones, el perfil del usuario final o los canales de soporte existentes, ya está proponiendo una arquitectura de microservicios distribuidos en la nube, con colas de mensajes, autenticación OAuth2 y despliegue en contenedores.

Suena impresionante. Pero, ¿es útil?

En contraste, el profesional con experiencia real responde con curiosidad, no con arrogancia. Te pregunta:
— ¿Quiénes son los usuarios? ¿Tienen conexión constante a internet?
— ¿Cuál es el volumen esperado de órdenes diarias?
— ¿Ya existe algún sistema legado que debamos integrar?
— ¿Qué métricas definen el éxito de este proyecto?

Esas preguntas no son una pausa antes de brillar. Son la esencia del trabajo bien hecho. Porque la tecnología no existe en el vacío. Existe para resolver problemas humanos, operativos, comerciales. Y esos problemas rara vez se resuelven con la herramienta más nueva, sino con la más adecuada.

Este enfoque no es modesto. Es riguroso. Y en una cultura que premia el ruido sobre la claridad, muchas veces pasa desapercibido. Mientras otros se apresuran a citar a arquitecturas de referencia sacadas de blogs de Silicon Valley, el verdadero experto está midiendo el terreno, evaluando riesgos, identificando puntos de fricción y priorizando funcionalidades que entreguen valor rápido.

Ahí está la diferencia: uno construye para impresionar, el otro construye para funcionar.

Esto también expone un sesgo peligroso en muchas contrataciones técnicas: se valora más la capacidad de hablar como si supieras todo, que la humildad de reconocer que no sabes lo suficiente aún. Se premia la seguridad teatral, no la competencia real. Y eso lleva a decisiones técnicas desbocadas, presupuestos inflados y proyectos que, aunque usan lo último en tecnología, fracasan al primer mes de uso real.

Peor aún, se normaliza la idea de que “si no está en la nube, no es serio” o que “si no es distribuido, no escala”. Pero en la práctica, muchas empresas no necesitan escalar a millones de usuarios. Necesitan algo que funcione hoy, que sea fácil de mantener, y que un equipo pequeño pueda operar sin depender de un ejército de DevOps.

Aquí radica otra señal de experiencia: la capacidad de decir “no”. No a una tecnología innecesaria. No a una funcionalidad que nadie pidió. No a una arquitectura compleja que nadie podrá sostener. Decir “no” es un acto de responsabilidad, no de limitación.

En cambio, quienes recién comienzan —o quienes jamás han tenido que mantener en producción lo que construyeron— suelen ver cada proyecto como una oportunidad para experimentar, para acumular buzzwords en su currículum. Y eso está bien… mientras no sea tu empresa la que paga las consecuencias.

Por eso, en una entrevista, fíjate bien: si la primera reacción de tu candidato es hablar de infraestructura, despliegue y patrones de diseño antes de entender tu negocio, ten cuidado. Podrías estar contratando a un fanático de la tecnología, no a un solucionador de problemas.

La experiencia real se reconoce no por lo que alguien sabe hacer, sino por lo que se niega a hacer hasta entender por qué debe hacerlo. Y eso, en un mundo obsesionado con la velocidad, es una cualidad cada vez más rara… y más valiosa.

No se trata de subestimar la técnica. Se trata de ponerla al servicio de algo más grande: el propósito del proyecto, la sostenibilidad del producto y la claridad del objetivo.

Porque al final del día, nadie en tu empresa va a celebrar que usaste la última versión de un framework. Pero sí van a agradecer que el sistema no se caiga, que sea fácil de usar, y que resuelva el problema para el que fue diseñado.

Y eso no lo logras con más tecnología. Lo logras con mejores preguntas.

#TecnologíaConSentido #ExperienciaReal #IngenieríaResponsable #MenosRuidoMásValor #DesarrolloÁgilConCabeza #PriorizaElProblemaNoLaHerramienta