¿Necesita un ingeniero frontend una carta de presentación?

El punto de partida honesto

La mayoría de solicitudes frontend pasan por un sistema de seguimiento de candidatos —Greenhouse, Lever, Ashby, Workday— antes de que un humano las vea. En muchos de estos sistemas el campo de carta de presentación es opcional, y cuando es opcional, un reclutador que hace una primera revisión de cuarenta solicitudes para un puesto está leyendo el CV y el enlace de GitHub, no la carta. Si has enviado tu solicitud a una gran empresa tecnológica y no has recibido respuesta, rara vez es por la carta. El currículum no coincidió con las palabras clave que buscaba el reclutador o el filtro del ATS, o el puesto tenía un candidato interno, o la vacante nunca estuvo realmente abierta. Esto no es razón para escribir una mala carta. Es razón para no dedicarle tres horas esperando que compense un CV que no muestra el stack en el primer tercio de la página.

Donde sí se lee la carta es en contextos más pequeños y específicos: startups y equipos de producto pequeños donde el responsable de contratación —a menudo el líder de ingeniería o un ingeniero senior, no un reclutador— lee personalmente cada solicitud porque hay veinte, no dos mil. Rutas de referencia, donde alguien reenvía tu solicitud directamente al equipo. Y procesos de etapas finales, donde eres uno de tres finalistas y alguien lee todo lo que enviaste porque está tratando de decidir entre tú y alguien más con un CV similar. En esas situaciones la carta puede genuinamente influir en la decisión. En una primera revisión basada en palabras clave en una gran empresa, generalmente no puede.

Qué debe hacer la carta, específicamente

Elimina las generalidades —"Soy un ingeniero frontend apasionado con gran atención al detalle" es cierto para cada solicitante y no responde nada— y una carta de presentación frontend realmente solo necesita hacer dos cosas.

Decir por qué este producto, no solo este stack. "He usado la app de [empresa] y lo que me hizo querer aplicar es X" es una frase diferente de "Me entusiasma la oportunidad de trabajar con React". Cada anuncio de trabajo frontend menciona un framework. Casi ninguno recibe una carta que mencione algo específico sobre la interfaz real —una funcionalidad que notaste, una pieza de UX que habrías construido diferente, un problema de rendimiento que encontraste en su sitio, un patrón de componentes que reconoces de su design system si es público. Si no puedes decir nada específico sobre el producto, vale la pena notarlo antes de escribir la carta, no después.

Mostrar que puedes hacerte cargo de algo, no solo escribir componentes. Pasado cierto nivel, el responsable de contratación no se pregunta si conoces JSX. Se pregunta si puedes llevar una funcionalidad desde un archivo Figma a producción sin que alguien te lleve de la mano —si has trabajado directamente con diseñadores e ingenieros backend, tomado una decisión sobre gestión de estado o estrategia de renderizado, resuelto un problema de compatibilidad de navegadores, o mejorado algo medible como el puntaje Lighthouse, el tamaño del bundle o Core Web Vitals. Un ejemplo concreto vale más que una lista de adjetivos. "Reconstruí la validación de formularios del flujo de checkout, lo que redujo una categoría de tickets de soporte casi a cero" les dice más que "sólidas habilidades de resolución de problemas".

Eso es todo. No tu historial profesional —eso es el CV. No por qué la ingeniería frontend como disciplina importa— nadie que contrata para este puesto necesita ser persuadido de eso. Solo: este producto, y aquí está la evidencia de que puedo hacer el trabajo al nivel para el que contratan.

Qué se ignora realmente, y por qué se sigue escribiendo

Algunas cosas aparecen constantemente en cartas frontend y rara vez ayudan:

"Me apasiona el código limpio y las mejores prácticas" —cada ingeniero dice esto y es infalsificable, por lo que no tiene peso para un responsable de contratación comparando candidatos. Si quieres hacer el mismo punto, nombra algo concreto: una configuración de linting o testing que introdujiste, una biblioteca de componentes que ayudaste a estandarizar, una migración que lideraste (componentes de clase a hooks, Redux a una biblioteca de estado más ligera, JavaScript a TypeScript). La especificidad es lo único que separa una afirmación real de una plantilla.

Repetir el CV en prosa. Si la carta simplemente describe tus últimos tres trabajos en forma de oraciones, está agregando extensión sin agregar información. Asume que el lector tiene el CV abierto junto a la carta.

Elogios genéricos a la empresa —"Siempre he admirado su cultura innovadora"— se lee como relleno porque sería cierto para cualquier empresa que pusieras en la frase. Si no tienes algo específico que decir sobre su producto, blog de ingeniería, trabajo de código abierto o design system, a menudo es mejor decir menos en lugar de escribir un párrafo que podría aplicar a cualquier empleador del sector.

Salario, disponibilidad y estado de visa pertenecen al formulario de solicitud o un email directo, no enterrados en un párrafo que el lector puede pasar por alto.

Dónde un portafolio o GitHub hace mejor el trabajo de la carta

Frontend es una de las pocas disciplinas de ingeniería donde generalmente puedes mostrar en lugar de contar —un proyecto desplegado, un perfil de GitHub con historial real de commits, un CodePen, un sitio personal que es en sí mismo una demostración de tu trabajo de CSS e interacción. Si tienes algo de esto, el trabajo de la carta cambia: no necesita convencer al lector de que puedes construir cosas, porque pueden ir a mirar. Necesita señalarles lo correcto y decir por qué es relevante. "El dashboard enlazado abajo usa el mismo enfoque de gráficos que necesitarías para la vista de analíticas mencionada en el anuncio" hace más trabajo que tres oraciones sobre tus habilidades.

Si no tienes un portafolio público —muchos buenos ingenieros frontend han pasado toda su carrera en trabajo interno o de cliente que no pueden compartir— dilo claramente en lugar de dejar un silencio que el lector llena por sí mismo, y apóyate más en el ejemplo específico de la carta.

Para procesos de contratación con muchas pruebas para llevar a casa, que son comunes en este nivel, la prueba en sí a menudo tiene más peso que la carta jamás tendrá. Si el proceso de una empresa incluye una ronda de codificación en vivo o una construcción para llevar a casa, ahí es donde ocurre la mayor parte de la evaluación. El trabajo de la carta en ese punto es solo meterte al proceso.

Qué hacer a continuación

Escríbela breve —cuatro a seis oraciones suelen ser suficientes. Nombra el framework o stack del anuncio de trabajo en la primera línea si genuinamente es tu mejor coincidencia, no como ejercicio de palabras clave sino porque es verdad. Da un ejemplo específico y medible de algo que construiste o arreglaste. Di una cosa específica sobre su producto. Corta cualquier cosa que sería igualmente cierta si cambiaras el nombre de otra empresa —si la oración sobrevive esa prueba, no está ganándose su lugar.

Si el verdadero obstáculo no es la carta —si estás enviando solicitudes sólidas a puestos que coinciden con tu stack y experiencia y aún así no recibes respuesta— el diagnóstico más útil suele ser el CV y la coincidencia entre tu experiencia y lo que el anuncio específicamente pide, ya que eso es en lo que la mayoría de filtros ATS y primeras revisiones de reclutadores realmente están filtrando. jobmarket.pro lee cada anuncio de trabajo completo, te dice dónde encaja tu experiencia y dónde no, y construye la solicitud desde un único perfil al que no puede inventarle experiencia, así que la carta y el CV son consistentes con lo que un responsable de contratación realmente verificará.