- El breve poema en prosa parte de la declaración “You are not a real engineer” y superpone en un mismo contexto una notificación de rechazo en una entrevista y la imagen de un monstruo mítico
- El sujeto es descrito como un ser trascendental con altura humana, cabeza de león, dieciséis alas y cientos de ojos, y un cinturón con forma de serpiente
- Un aliento como nubes de tormenta, una voz como el rugido del viento y unos pasos que marchitan la hierba siguen ampliando el poder abrumador del sujeto
- Al final aparece la frase de rechazo laboral “no vamos a ofrecerte este puesto en este momento”, seguida de la razón: “estamos buscando a alguien más técnico”
- Incluso un ser destructivo es rechazado por no ser alguien más técnico, lo que deja en evidencia lo absurdo del criterio de un “verdadero ingeniero”
Descripción que se expande hacia un ser mítico
- La frase inicial es “You are not a real engineer”, una declaración directa de que el sujeto no es un verdadero ingeniero
- Después, el sujeto crece hasta convertirse en un ser con cuerpo humano y cabeza de león, descrito además con dieciséis alas blancas y cientos de ojos como antorchas
- El cinturón de su cintura es una serpiente, su aliento es una reunión de nubes de tormenta y su voz se acerca más al rugido del viento
- Ante sus pasos la hierba se marchita, y una lengua negra como un abismo profundo lleva el fin a todo lo que toca
El giro que produce la frase de rechazo laboral
- El cierre cambia de forma abrupta desde una descripción abrumadora hacia la fórmula cortés de rechazo propia de un proceso de contratación
- Después de “no vamos a ofrecerte este puesto en este momento” aparece la razón: “estamos buscando a alguien más técnico”
- El choque entre la imagen mítica anterior y la última frase común de rechazo laboral deja al descubierto la fragilidad de lo que significa “verdadero ingeniero”
1 comentarios
Opiniones en Hacker News
Últimamente dejé de lado la idea de contratar ingenieros geniales para puestos en los que el 80% del horario laboral consiste en crear aplicaciones CRUD.
Es un desperdicio de dinero y de talento, no es bueno para el candidato y a largo plazo también se vuelve un riesgo para la empresa. Esas personas terminan aburriéndose y es muy probable que empiecen a sobrediseñar solo para poder usar la cabeza.
Para la mayoría de los ingenieros, basta con que puedan escribir correctamente operaciones de crear, modificar, borrar y consultar a nivel de base de datos y API, llamar a la API desde el frontend, y contar con un manejo de errores adecuado y un enfoque decente de debugging.
Pero también he visto programadores “decentes” que entregan resultados “más o menos”, y programadores mejores que trabajan 5 veces más rápido sin trabajar 5 veces más horas, se gestionan casi solos, no necesitan que QA esté encima para verificar si un ticket marcado como terminado realmente está terminado, y resuelven problemas de forma creativa sin que alguien tenga que destrabarles el repositorio de Git cuando algo sale mal.
No necesitas una mente dispersa, pero los buenos/grandes programadores hacen una gran diferencia incluso en proyectos que técnicamente parecen comunes.
Últimamente me metí mucho con Steve Howe, y vi que él, considerado uno de los mejores guitarristas de la historia, dijo algo como que le gustaría que los guitarristas se enfocaran en convertirse en intérpretes. La diferencia entre coders e ingenieros es parecida.
He visto muchos programadores técnicamente más capaces que yo, pero no eran mejores ingenieros. Que yo sea fundador y tenga algo de experiencia en marketing influye mucho.
Muchas empresas subestiman las habilidades no relacionadas con programar que en realidad forman a un ingeniero. Es como contratar a un carnicero en vez de un chef y luego preguntarse por qué la comida no sabe bien.
Obtener una licenciatura en un área técnica, trabajar como ingeniero #52354 en un lugar como Ingersoll Rand o Boeing, especializarse durante 30 años en un dominio complejo pero acotado y luego jubilarse también es una gran carrera. Esa también es una definición válida de “ingeniero”, y aunque esas personas puedan parecer aburridas, es muy probable que lleven vidas personalmente satisfactorias.
He pensado mucho en este tema últimamente: la gerencia suele ver al ingeniero estándar como un centro de costos, mientras que alguien como el del texto puede escapar de esa crítica porque su valor se extiende más allá de ingeniería, incluso hacia otros departamentos que generan ingresos directamente.
Creo que yo también soy un ingeniero de ese tipo, pero he intentado transformar mi desprecio por ese estereotipo en una actitud más colaborativa.
El mercado real valora más a un coder de Spring Java que a un ingeniero de C++ que trabaja con hardware.
He pasado por ambos lados. Sufrí los caprichos inexplicables y las pequeñas humillaciones del proceso de búsqueda de empleo, y también entrevisté y rechacé a candidatos con experiencia que hablaban muy bien pero no podían programar un problema de nivel FizzBuzz en ningún lenguaje.
No se trata de elegir solo una entre “las entrevistas técnicas son un desastre” y “en el mercado laboral hay muchos candidatos no calificados”. Ambas pueden ser ciertas y, de hecho, creo que están conectadas como en un mercado de limones.
Aunque haya alguien objetivamente mejor, igual puedes ser contratado; y aunque seas el candidato ideal, pueden descartarte de inmediato en el screening telefónico. Al final se parece mucho a la suerte, y quienes dicen que no mezclan sesgo de supervivencia con falta de voluntad para admitir que el proceso en sí tiene fallas.
También creo que juzgar que un candidato con experiencia no pudo resolver algo de nivel FizzBuzz refleja el pensamiento de culto al cargo que aqueja a la contratación. Conozco ingenieros de FANG que tienen que practicar durante semanas coding golf y preguntas de algoritmos y estructuras de datos, que no se parecen al trabajo real de ingeniería de software, solo para pasar la primera entrevista.
Incluso pienso que estos problemas se parecen más a patear la escalera que a evaluaciones técnicas. Una vez me descartaron automáticamente para un puesto de C++ desarrollando apps de escritorio porque no sabía qué era placement new, y a un conocido que postuló a un puesto de backend lo rechazaron porque, aunque creó desde cero un servicio Spring y pasó todas las pruebas de integración, no había comentarios en los controladores. Hay entrevistadores que rechazan candidatos por cosas que podrían corregirse con un comentario de una línea en un PR, como si fueran grandes desafíos técnicos.
Quienes contratan también cometen errores. Contratar bien es realmente difícil.
A veces te salvan de trabajar en un lugar con personas que, de todos modos, no te habrían caído bien. Tampoco son muy buenos inventando excusas plausibles sobre por qué no te contrataron, y buena parte de todo esto es suerte.
Por ejemplo, quizá tuvieron la impresión de que “no pareces simpatizante de Trump” y sintieron que no podrían convivir cómodamente contigo. Si de verdad no eres de los suyos, ¿por qué querrías trabajar ahí?
Buscar empleo siempre me deprime, y no conozco otra respuesta más que no poner demasiadas expectativas en un puesto específico. Al mismo tiempo, tampoco hay que descartar demasiado fácil oportunidades que no parecen gran cosa.
Mi primer jefe en mi trabajo actual era terrible y tampoco había mucha gente buena, pero ellos se fueron de la empresa y yo ascendí. ¿Cómo se puede predecir algo así? El reclutador tampoco puede predecirte a ti; todo el proceso es bastante aleatorio e incómodo.
Cuando estoy del lado de quien entrevista, tengo prioridades. Primero, mi jefe me dio un consejo breve: “intenta contratar a buenas personas”. Prefiero trabajar con un buen desarrollador que sea amable, colaborador y con quien se pueda convivir, antes que con alguien que siempre tenga que imponer su voluntad y crea que, por ser un genio hiperproductivo, debe tener control total.
Segundo, miro si el candidato tiene interés en el software o al menos en algo. Si no tiene ni un poco de pasión por el software, la tecnología o algo relacionado con el trabajo, ¿cómo va a aprender lo que haga falta y que no está en su CV? Hay que esperar que las personas aprendan; no llegan como “productos terminados”.
Creo que incluso un buen proceso de entrevistas inevitablemente puede rechazar a algunos candidatos que en la práctica habrían hecho muy bien el trabajo.
Para entender de verdad si una persona encaja con el puesto, el tiempo que tendrían que dedicar tanto el empleador como el candidato al proceso de entrevistas se vuelve demasiado grande. Para el empleador también es una mala asignación de recursos, y para el candidato resulta difícil de aceptar.
Idealmente, estaría bueno que el candidato fuera a la oficina y completara por su cuenta un pequeño proyecto de programación durante un día, pero en la práctica no es viable.