¿Se lee la carta de presentación de un ingeniero backend?

Has enviado muchas solicitudes y has recibido muy poca respuesta, y en algún lugar de esa pila hay una pregunta que sigues debatiendo: ¿la carta de presentación está sirviendo de algo?

Respuesta honesta: para gran parte de los puestos backend, no. No mucho. El CV, la recomendación y la ronda de diseño de sistemas lo deciden. Pero hay un conjunto reducido de situaciones donde la carta es lo único que puede salvar una solicitud, y si estás recibiendo silencio, hay una probabilidad razonable de que estés en una de ellas y escribiendo la carta equivocada.

Esto se trata de descubrir en qué situación te encuentras.

Con qué compite la carta

Un gerente de contratación backend que cubre una vacante tiene una pila de CVs, una o dos recomendaciones, y un proceso que termina en una entrevista técnica que les dirá mucho más que cualquier texto. Para un puesto de nivel intermedio con un stack bien definido, el filtro es principalmente mecánico: ¿tiene esta persona experiencia en producción en algo cercano a lo que ejecutamos, a una escala cercana a la nuestra, en un dominio cercano al nuestro?

Por eso tu carta a menudo no hace nada. No porque nadie lea textos, sino porque la decisión en esa etapa no necesita textos. Si el anuncio dice Go, Postgres, Kubernetes, event-driven, y tu CV dice cinco años de Go y Postgres en un equipo que gestionaba su propio clúster de Kafka, la carta es redundante. Pasas por el CV. Si tu CV dice cuatro años de PHP y un monolito Laravel en una única instancia RDS, una carta muy buena difícilmente cambiará la aritmética de un filtro con noventa candidatos más.

La carta gana su lugar en la banda intermedia — donde un humano mira tu CV, duda, y necesita una razón para seguir leyendo.

No conozco datos públicos fiables sobre con qué frecuencia se leen las cartas de presentación para puestos de ingeniería específicamente, y cualquiera que te cite un porcentaje se lo está inventando. Lo que sí puedes observar directamente es el formulario de solicitud. Si el campo de la carta de presentación está marcado como opcional, esa es una señal de cuánto espera el proceso de ella. Si el formulario en cambio te hace una pregunta escrita específica — "describe un sistema que diseñaste y que ahora construirías de forma diferente" — esa es una señal en la otra dirección, y debe responderse como una pregunta de entrevista, no como una carta.

Dónde sí se lee

Cinco situaciones, en orden aproximado de cuánto marca la diferencia la carta.

La empresa tiene menos de unos cincuenta ingenieros y el gerente de contratación lee las solicitudes personalmente. En una empresa en fase semilla o Serie A, la persona que decide es a menudo quien hará code review de tus PRs. No están filtrando contra una vacante; están intentando imaginarte en el equipo. Leerán dos párrafos. También notarán si claramente no has mirado qué construyen.

Eres una coincidencia atípica. De Java a Go. Backend a backend, pero de ad tech a salud, o de un mundo batch intensivo en datos a uno de baja latencia request/response. De una empresa de 400 ingenieros a una de 12 personas, o al revés. Nadie lee un CV y concluye espontáneamente que tu experiencia se transfiere. Tienes que decirlo, y decir por qué, de forma que muestres que entiendes qué es realmente diferente sobre su problema.

Hay una discontinuidad que alguien tendrá que explicar. Un hueco de dos años. Tres trabajos en tres años. Un despido. Un título que dice "Full Stack" cuando el trabajo fue noventa por ciento backend. Te fuiste sin un puesto superpuesto. Alguien en el proceso lo planteará. La carta decide si lo plantean como pregunta o como razón para rechazar.

Contratación regulada o del sector público donde la solicitud escrita se puntúa. Los puestos del UK Civil Service reclutados bajo Success Profiles piden evidencia contra comportamientos nombrados y una declaración personal, y estos se evalúan contra un marco publicado en lugar de leerse por encima. El mismo patrón de formulario estructurado aparece en puestos relacionados con NHS Digital y algunas empresas autorizadas por FCA. Aquí la presentación escrita no es una cortesía — es el filtro. Escríbela contra el marco, usando su vocabulario, con un ejemplo por comportamiento.

Puestos staff y principal. Por encima de senior, una fracción grande del trabajo es escrito: design docs, RFCs, ADRs, el memo que logra que cuatro equipos acuerden un esquema de eventos antes de que alguien escriba código. Un gerente de contratación para un puesto staff backend está leyendo tu carta en parte como muestra de escritura. Si son tres párrafos de entusiasmo genérico, esa es información sobre cómo escribirías un RFC.

Dónde se ignora

Procesos de grandes empresas con un reclutador filtrando contra una vacante estructurada. El trabajo del reclutador es comparar tu CV contra una lista de verificación y pasarte a una llamada de screening. La carta generalmente no es parte de ese flujo, y escribir una más larga no lo cambiará.

Procesos impulsados por recomendaciones. Si alguien interno dio referencias por ti, ya pasaste la etapa que la carta aborda.

Solicitudes enviadas por agencias. El reclutador frecuentemente reformatea tu CV en su propia plantilla antes de que el cliente lo vea. Tu carta puede no sobrevivir ese paso en absoluto.

Y cualquier proceso donde la primera barrera real es un ejercicio para llevar a casa o una evaluación online. Si el anuncio dice "solicita y recibirás un ejercicio de código", la carta es un campo administrativo.

Las dos cosas que un gerente de contratación backend quiere que la carta responda

Uno: ¿entiendes qué hace realmente este sistema, y quieres trabajar en ese problema específico?

No "por qué quieres trabajar en Monzo". Por qué este sistema. Los puestos backend se definen por sus restricciones, y las restricciones difieren enormemente entre anuncios que usan palabras idénticas. "Sistemas distribuidos" en una empresa de pagos significa claves de idempotencia, semántica exactly-once que es realmente at-least-once con deduplicación, corrección del ledger, y reconciliación. En un ad exchange significa un presupuesto p99 medido en milisegundos de un dígito y disposición para descartar solicitudes. En una empresa de logística significa flujos de trabajo de larga ejecución, transacciones compensatorias y mucho estado que vive durante semanas.

Si puedes escribir dos frases mostrando que sabes a cuál estás aplicando, ya estás por delante de la mayoría de la pila. Los equipos backend dejan evidencia por ahí: blogs de ingeniería, repos de código abierto, charlas de conferencias, documentación de API públicas, write-ups de incidentes. Lee uno. Referencia la cosa real. "Tu post sobre mover el flujo de settlement fuera del monolito mientras escribías en doble durante seis semanas — ese problema de cutover es la parte del trabajo que querría" vale más que cualquier cantidad de entusiasmo declarado, porque no puede ser producido por alguien que no hizo el trabajo.

Dos: ¿cuál es la razón para rechazarte, y cuál es tu respuesta?

Cada solicitud tiene una. Encuentra la tuya y abórdala en una o dos frases, sin disculparte.

El desajuste de stack: "El anuncio dice Kotlin y Spring Boot. Mi trabajo JVM ha sido Java con Dropwizard y Micronaut — mismo modelo de concurrencia, mismos problemas de tuning de JVM, y he enviado Kotlin en servicios secundarios. Esperaría ser lento en Kotlin idiomático durante un mes".

La cuestión de escala: "No he ejecutado nada a vuestro volumen de peticiones. Lo que sí he hecho es llevar una instancia Postgres de un único escritor a replicación lógica más réplicas de lectura cuando nuestro flujo de lectura empezó a fallar, lo que me enseñó más sobre query planning que sobre escala".

La cuestión de ownership en producción, que es la que los gerentes de contratación más a menudo no pueden responder desde un CV: ¿has llevado un pager? ¿Has sido la persona que se despertó a las 3am con una alerta de lag del consumer de Kafka y tuvo que decidir si reproducir o descartar? Los equipos que gestionan su propia rotación de guardia se preocupan por esto mucho más de lo que sugiere el anuncio, y casi ningún CV lo declara. Una cláusula: "He estado en una rotación de guardia de seis personas durante los últimos tres años, incluyendo el flujo de pagos".

Ese es todo el trabajo de la carta. Muestra que entiendes el sistema específico. Anticipa la objeción. Todo lo demás es relleno.

Qué cortar

El párrafo de apertura anunciando que estás escribiendo para solicitar el puesto de Senior Backend Engineer. El lector lo sabe.

La lista de tecnologías que ya están en tu CV. Si la carta repite el CV, le ha costado tiempo al lector y no le ha dado nada.

Adjetivos sobre ti mismo. "Apasionado", "altamente motivado", "resolvedor de problemas fuerte" — estos son no falsables y todo el mundo los escribe, que es exactamente por qué no transmiten información.

El párrafo de historia de la empresa. Decirle a una fintech en qué año se fundó no demuestra investigación. Referenciar su enfoque de reintentos idempotentes sí.

Cualquier cosa de más de una página. Para la mayoría de los puestos backend, de tres a cinco párrafos cortos es la longitud honesta, y las excepciones de solicitud estructurada arriba son estructuradas precisamente porque quieren algo diferente.

Qué se repite y no está respaldado

Que una carta de presentación debe dirigirse a un individuo nombrado o será descartada. Dirigirla a una persona está bien y es levemente mejor que "Estimado Sr./Sra.". No hay buena evidencia de que la ausencia de un nombre te haga rechazar, y los gerentes de contratación en empresas que no publican su organigrama saben perfectamente bien que no pudiste encontrar el nombre.

Que debes hacer keyword-matching en la carta para pasar el filtrado automatizado. El filtro que importa para puestos backend es generalmente un reclutador o gerente de contratación leyendo un CV, y los applicant tracking systems son principalmente herramientas de almacenamiento y flujo de trabajo en lugar de motores de rechazo automatizado. Meter Kubernetes en una frase donde no pertenece te cuesta con el humano y probablemente no te compra nada con la máquina. Asegúrate de que las tecnologías genuinamente requeridas aparezcan en tu CV en palabras simples, porque un reclutador bien puede estar buscándolas — eso es un problema de CV, no de carta.

Que siempre debes adjuntar una. Si el campo es opcional y no tienes nada específico que decir sobre ese sistema, una carta genérica es levemente peor que ninguna carta, porque demuestra que aplicaste sin leer.

Qué hacer a continuación

Revisa tus últimas veinte solicitudes y ordénalas en dos pilas: aquellas donde un gerente de contratación humano plausiblemente leyó la solicitud, y aquellas que fueron a un proceso de gran empresa o agencia. Si el silencio está concentrado en la segunda pila, la carta no es tu problema y reescribirla es procrastinación — mira el CV, el ajuste de stack, y si tienes alguna ruta a una recomendación.

Si el silencio está en la primera pila, elige los cinco puestos que más quieres, y para cada uno escribe dos cosas antes de escribir cualquier texto: la cosa específica que su backend hace que es técnicamente interesante, tomada de algo que publicaron, y la razón única más clara por la que alguien te rechazaría. Si no puedes llenar la primera casilla después de quince minutos de buscar, esa es información útil sobre si aplicar en absoluto.

Luego escribe cuatro párrafos. Su sistema. Por qué ese problema. Tu objeción y tu respuesta a ella. Una línea sobre disponibilidad. Para.

Si el cuello de botella es que hacer esto correctamente toma una hora por anuncio y tienes cuarenta que completar, jobmarket.pro lee cada anuncio completo y redacta la solicitud desde un perfil de tu experiencia real, sin inventar nada.