El león, la bruja y el descaro del reclutador
(hauleth.dev)- Un candidato critica cómo, al pasar por los procesos de contratación de dos empresas, la inconsistencia del rol y la asimetría de feedback consumen el tiempo de los postulantes
- Hop.NS realizó un trial contract de 1 semana para una posición de “Senior Elixir Developer”, pero la tarea real era el mantenimiento de una extensión de navegador en TypeScript y el agregado de funciones de UI
- Al inicio de la trial week se perdió tiempo obteniendo acceso a Slack, GitHub y plantillas de diseño, y recién después de unas 10 a 12 horas pudo ejecutar la extensión en local
- PerhapsMaybe realizó más de 5 horas de entrevistas técnicas y luego se negó a dar feedback individual, pero una semana después envió una encuesta de experiencia de candidato para pedir feedback solo al candidato
- Si una empresa exige mucho tiempo y dedicación, también debería ofrecer precisión en la descripción del rol, motivos de rechazo personalizados y respeto por los candidatos
Hop.NS: una trial week que pasó de un puesto de Elixir a una tarea con extensión de navegador
- El candidato vio en LinkedIn una vacante de Hop.NS, donde trabajaba un excompañero, y postuló
- El nombre de la empresa y algunos detalles fueron cambiados para evitar problemas legales
- En el pasado, la empresa pedía un take-home project de 1 semana y pagaba por ese tiempo
- La vacante era para Senior Elixir Developer, y en la llamada con el CTO se hablaron del rol de desarrollador Elixir, el equipo y los procesos
- El CTO explicó que durante un trial contract de 1 semana haría “el trabajo que tendría si lo contrataran”
- La documentación contractual avanzó sin problemas y la trial week empezó el lunes a las 09:00
Día 1: problemas de acceso y revelación de la tarea real
- El primer día recibió credenciales temporales de correo de la empresa, pero no podía entrar al workspace de Slack y solo aparecía un mensaje para contactar al administrador
- Como no tenía un medio de contacto, le escribió por LinkedIn a un conocido dentro de la empresa para pedir ayuda con el acceso
- De un contrato de 40 horas, se consumieron 2 a 3 horas por el problema de acceso a Slack
- Luego también tuvo que pedir acceso a GitHub y esperar, hasta que finalmente pudo clonar el repositorio
- Como el supervisor estaba en Sudamérica, la llamada para explicar la tarea quedó agendada a las 18:00; hasta entonces revisó la base de código en Elixir y abrió un PR con una corrección pequeña
- En la llamada de la noche, se reveló que la tarea de la trial week era el mantenimiento de una extensión de navegador en TypeScript y el agregado de una nueva función y diseño de UI
- El candidato confirmó que tenía poca experiencia en esa área, pero el responsable respondió que esa era la tarea correcta
- El responsable dijo que “todo el trabajo de backend ya estaba terminado, así que no tenía que preocuparse”
- El candidato entendió que el trabajo de backend/Elixir que quería ya estaba terminado y que ahora debía hacer una tarea de carácter frontend que no quería
Día 2: configuración del entorno y confirmación de la inconsistencia del rol
- El segundo día tuvo que instalar Google Chrome para ejecutar y entender la extensión de navegador
- El candidato normalmente prefería Safari y Firefox, y evitaba usar Chrome
- Le tomó varias horas entender cómo compilar y ejecutar en local, y tuvo que seguir contactando a otras personas para obtener credenciales y accesos adicionales
- En una conversación con el conocido que lo había recomendado, preguntó si era normal que la tarea de una trial week pudiera ser completamente distinta del área de especialidad del candidato
- El conocido respondió que a veces ponen a los candidatos fuera de su comfort zone, pero que si a un desarrollador backend le dan una tarea puramente frontend, algo salió mal
- También dijo que, en la misma situación, él habría detenido el proceso de inmediato
- El candidato decidió continuar el proceso por respeto a las dos personas que lo habían recomendado
- En el canal de Slack dedicado a la contratación preguntó “si al ser contratado seguiría a cargo de este proyecto o haría otra cosa”, y la respuesta fue “no siempre es así”
- Tuvo que volver a buscar al responsable para recibir la plantilla de diseño, y recién después de 10 a 12 horas de las 40 horas de la trial week pudo ejecutar la extensión de navegador en local
Día 3: ampliación del alcance de la tarea y suspensión de la trial
- Para el tercer día ya entendía en cierta medida la forma de trabajo y lo que hacía falta, pero seguía teniendo poco conocimiento sobre depuración de extensiones de navegador
- Cerca del mediodía del tercer día, a mitad de la trial week, la empresa amplió aún más el alcance de la tarea
- El candidato envió un mensaje largo quejándose de que la tarea no coincidía en absoluto con lo que le habían comunicado durante el proceso de contratación
- La descripción del puesto no mencionaba TypeScript ni extensiones de navegador
- Él había enfatizado varias veces que era un ingeniero con perfil “backend-and-ops”
- Consideraba que esa tarea desperdiciaba tanto su tiempo como el de la empresa
- Aclaró que la única razón por la que no la había detenido de inmediato era el respeto por los conocidos que lo habían recomendado
- El CTO respondió que intentaban comprobar si “encajaba con la cultura”, dijo que no sentía que la empresa hubiera hecho algo mal y pidió que no publicara el texto
- Hop.NS pagó por unas 20 horas de trabajo dolorosas
- Entre 3 y 4 semanas después, el CTO le preguntó por LinkedIn si le interesaba una posición de Staff Software Engineer, y el candidato le preguntó si todavía usaban tácticas de bait-and-switch
PerhapsMaybe: después de una larga entrevista no hubo feedback, pero sí pidieron una encuesta
- PerhapsMaybe tenía abierta una posición de Software Engineer with Elixir, y el candidato postuló porque conocía a varias personas en la empresa
- Un conocido puso su postulación frente al VP of Infrastructure, que parecía ser el hiring manager de la posición, pero el proceso no fue rápido
- La información de postulación se envió el 27 de mayo de 2026
- El primer contacto del equipo de reclutamiento llegó el 11 de junio de 2026, más de dos semanas después
- Recién después de enviarle una invitación al VP en LinkedIn, el reclutador se puso en contacto
- La llamada de 1 hora con el VP salió bien y aumentó su interés por el rol
- Luego siguió la coordinación de las entrevistas técnicas, y el bloque completo quedó programado para 5 horas y 30 minutos
Estructura de las entrevistas de PerhapsMaybe y notificación de rechazo
- Las entrevistas se hicieron en un solo día, con descansos de 30 minutos y 2 horas entre sesiones
- La estructura tuvo tres partes
- Systems Design de 1 hora: diseñar un sistema de pagos asíncrono usando una pasarela de pagos síncrona
- Coding Interview de 1 hora: ejercicios similares a LeetCode, como cross product y movimientos de piezas de ajedrez sobre un keypad
- Technical Deep Dive de 1 hora: explicación de detalles técnicos de un proyecto pasado, Ultravisor
- El candidato cometió un error en el análisis de complejidad big-O en el segundo ejercicio de la entrevista de coding, pero en general sintió que la solución estaba bien
- En el Technical Deep Dive él sintió que le fue bien, pero tuvo la intuición de que la otra parte no quedó impresionada o esperaba otra cosa
- Hacia el final del segundo día después de la entrevista, pidió una actualización al reclutador y recibió la notificación de rechazo
- El correo de rechazo incluía la frase “debido al alto volumen de postulantes, no damos feedback individual”
La asimetría de feedback creada por la encuesta de experiencia de candidato
- Una semana después del rechazo, el Hiring Team de PerhapsMaybe envió un correo de Candidate Experience Survey
- El correo decía que querían verificar si el proceso de contratación era eficiente y si la experiencia del candidato era buena, y pedía feedback honesto y puntos de mejora sobre la experiencia reciente de entrevistas
- El candidato consideró que la empresa probablemente tenía unas 5 horas de grabaciones y notas automáticas de reuniones
- Él señaló que tenía prohibido usar IA para tomar notas de las reuniones
- Criticó que la empresa no ofreciera 3 o 4 frases personalizadas sobre las razones del rechazo, pero sí pidiera al candidato feedback para mejorar el proceso
- El candidato sintió que lo trataron no como candidato, sino como un contratista que evaluaba el proceso de contratación, y pidió los billing details para enviar una factura con su tarifa de contratista
Críticas al mercado de contratación y un caso positivo excepcional
- El candidato expresó que el mercado laboral actual está roto
- Mencionó que algunos recruiters critican el uso de LLM durante los procesos de postulación
- Criticó que las postulaciones a menudo incluyan preguntas como “por qué quieres trabajar en XYZ” o “qué es lo que más te entusiasma de trabajar en XYZ”
- El candidato considera que no es su trabajo describir el producto de la empresa como si se lo estuviera revendiendo a la propia empresa
- Dijo que quiere hacer un trabajo que le interesa y recibir dinero a cambio
- Expresó que los únicos que pueden estar genuinamente entusiasmados con el producto de una empresa son los fundadores, y que después de una IPO incluso los accionistas solo quieren que suba el valor
- Como excepción, en el proceso de postulación a Fresha, Christine Wong fue un caso positivo
- El motivo del rechazo fue “falta de experiencia con coding agents”
- Christine Wong pidió agendar una llamada para entregar personalmente feedback personalizado
- El candidato dijo que fue bueno ver a una persona real mostrando respeto por los candidatos, y agradeció esa experiencia
1 comentarios
Opiniones en Lobste.rs
Decir que es una forma de empujar a los candidatos fuera de su zona de confort suena a fabricar una excusa para contratar a la persona que quieren e ignorar otros factores.
Pedirle a un desarrollador backend que haga trabajo puramente frontend y luego evaluar su “encaje cultural” es como culpar a un pez por no poder trepar un árbol.
Mientras los trabajadores no controlen las contrataciones y los despidos del equipo, al menos de su propio equipo, parece que este tipo de juegos va a seguir.
No sentí mucha empatía por el autor de este texto.
En un entorno corporativo, no es tan sorprendente que conseguir permisos de acceso o hablar con alguien en otra zona horaria tome un día, y cómo se reacciona ante esa situación es una buena señal para evaluar el encaje cultural.
Tampoco sorprende que lo más urgente quede fuera del alcance del rol definido de antemano, y un candidato capaz de trabajar fuera de su área le resulta más valioso a una empresa que alguien que se queda solo dentro de un alcance específico.
Por supuesto, si se le pide a alguien trabajar fuera de su especialidad, inevitablemente avanzará más lento y los resultados pueden ser peores, pero es probable que la empresa prefiera eso antes que un rechazo outright.
Que un reclutador tarde semanas en coordinar entrevistas, o que contactar a un vicepresidente por LinkedIn acelere el proceso, tampoco es raro en un entorno corporativo. Saber cuándo contactar al vicepresidente también forma parte del trabajo.
Si el reclutador pidió feedback sin darle feedback al candidato, decir que eso fue lo más memorable puede ser, en sí mismo, un buen feedback.
Lo que más me molestó fue la palabra “bitch” tachada al principio. Nunca está bien referirse así a un colega o posible colega. Puede haber desacuerdos, pero los ataques personales dirigidos al género no.
La vacante describía un trabajo puramente backend, y también dije que casi todo lo que he hecho ha sido backend y operaciones de sistemas.
Pero si me ofrecen un trabajo puramente backend y de pronto me dan una tarea de la que no sé absolutamente nada, esperando una solución funcional con “un diseño que encaje con el resto del sistema” en un máximo de 32 horas, no puedo verlo sino como una falta de respeto a mi experiencia y conocimiento.
He trabajado más de 10 años como desarrollador backend, de los cuales unos 7 fueron en observabilidad y rendimiento, y lo más relativamente cercano a frontend que hice fue agregar funcionalidades a una aplicación Vua existente hace 8 años.
Si intentan evaluar mi experiencia y conocimiento con una tarea así, no tengo más opción que concluir que no me quieren. En vez de decirlo con cortesía, obligarme a sufrir con trabajo sin sentido me parece casi un insulto.
Que el proceso de contratación tomara semanas también me sorprendió. Un ingeniero senior/principal/staff de esa empresa me había recomendado con ese vicepresidente dos semanas antes, y yo sabía que el vicepresidente lo había confirmado.
Sí di feedback, y también le pedí al reclutador la información de facturación para poder cobrarles consultoría sobre su proceso de contratación.
Por suerte, también hay otras formas de obtener feedback. Como estoy en la UE, gracias al GDPR puedo solicitar todas las notas y detalles sobre mi proceso de contratación.
El lenguaje corporativo existe para que incluso dos personas que están en lados totalmente opuestos en todas las grandes preguntas de la vida puedan avanzar juntas de forma excelente hacia los objetivos de la empresa.
Yo lo leí de manera parecida. Entiendo que es un desahogo entre amigos, pero si hubiera visto aunque fuera un poco de esa actitud durante la etapa de entrevistas, probablemente habría rechazado la entrevista.
La disposición a trabajar fuera de la propia especialidad no solo es valiosa para un empleador, también puede abrir oportunidades de carrera y aprendizaje que no aparecerían si uno insiste en quedarse solo dentro de su área.
Lo importante es comunicar dónde está ese límite para ajustar expectativas y plazos adecuadamente, y la capacidad de hacerlo ya es una señal fuerte en una entrevista.
Dicho eso, hace falta equilibrio. Si la dirección de tu carrera ya está muy clara y el proyecto que te piden no te lleva hacia allá, quizá convenga usar el tiempo en otra cosa.
Pero no creo que tomaría como un insulto personal que mis objetivos y los del empleador entren en conflicto, ni arriesgaría quemar puentes por eso.
Con solo leer esto, no lo contrataría; se siente inmaduro y poco profesional.
Hace poco me pasó algo bastante interesante. Un reclutador de una empresa me contactó para preguntarme si me interesaba hablar, y acepté porque uso el producto de esa empresa todos los días.
Cuando empezó la llamada, el reclutador preguntó: “Entonces, ¿qué estás buscando?”, pero yo no estaba buscando nada. Como ellos se acercaron, pensé que no se trataba de que yo convenciera a la empresa, sino de que la empresa intentara convencerme a mí.
Aun así, pensé que era solo una frase común, y hablamos cerca de una hora sobre lo que hacía la empresa y demás. Al final me preguntó si me interesaba continuar con un proceso que podía incluir tres entrevistas técnicas y terminar en una oferta, y como estoy en una posición relativamente favorable con un empleo estable, me pareció interesante y acepté.
El reclutador dijo que enviaría un correo después de la llamada, y nos despedimos.
Pero el correo no llegó durante casi una semana. Al final le escribí preguntando si quizá se le había olvidado, y unos días después recibí una respuesta diciendo que habían decidido no avanzar con el proceso esta vez.
Fue como recibir un rechazo sin siquiera haber postulado, y extrañamente me dolió.
Pero la cosa no terminó ahí. Unas semanas después estaba asistiendo a una gran conferencia de programación, y el reclutador me escribió diciendo que ellos también estaban allí, invitándome a cenar y preguntando si tal vez me interesaba reiniciar el proceso de entrevistas.
Como ellos pagaban, fui a la cena y tuve una conversación agradable con varios ingenieros de la empresa. Pero me pareció raro por qué reiniciar era una opción si yo no había detenido el proceso, y por qué eso quedaba como si fuera mi responsabilidad.
Siento que hace falta una página muy leída, algo así como una guía del entorno corporativo de TI, para prepararse ante interacciones de este tipo.
No intento defender lo que pasa ahí, pero mucha gente no conoce bien la realidad.
Hay retrasos, tanto internos como externos. Perder un día en el proceso de conseguir permisos de acceso es normal y previsible.
Los procesos se demoran, y uno se convierte en un pequeño engranaje dentro de un proceso que mira métricas generales, no el éxito o fracaso individual.
Muchos lugares tienen una política de no dar feedback de forma generalizada. La pérdida potencial es una demanda, y no hay beneficio potencial.
La comunicación a menudo es mala, y también puede pasar que cambien o se omitan pruebas del puesto.
Una guía así podría alinear expectativas y también filtrar a quienes no quieren lidiar con esa rutina.
Para terminar dentro de ese plazo, tuve que conseguir permisos de acceso usando canales de comunicación de terceros y personas fuera del proceso.
En el trabajo normal, uno puede esperar, así que los retrasos pueden ser normales; pero un proceso de contratación no debería afectar mi trabajo diario. Esa es una gran diferencia.
Sobre la política de no dar feedback, como estoy en la UE y aplica el GDPR, puedo solicitar todos mis detalles y notas internas.
Al final, lo único que obtienen es la impresión de falta de profesionalismo y que todo este proceso se sienta más como consultoría sobre procesos de contratación que como una contratación legítima.
Alinear expectativas y filtrar personas puede estar bien, pero si digo que necesito más tiempo, dudo mucho que ellos apliquen el mismo criterio. Por eso se crea una ventaja injusta.
Mirando hacia atrás, tal vez no debí hacer nada, ni insistir pidiendo acceso, sino esperar hasta el fin de semana a que sus máquinas funcionaran y luego simplemente cobrar el pago. Creo que me habría preocupado menos.