Inglés para developers: performance reviews
Cómo hablar de tu impacto en inglés en tu performance review
21 de octubre de 2026
Las frases exactas para escribir una autoevaluación sólida y hablar de tu trabajo en inglés, sin subestimarte y sin sonar arrogante.
Puntos clave
- La fórmula: qué hiciste, el resultado medible, por qué importó. La mayoría de los developers solo escribe la primera parte.
- Un resultado cualitativo es mejor que ningún resultado. No necesitas un porcentaje en cada línea, necesitas un 'por esto, X cambió'.
- Nombra tu contribución individual incluso en un proyecto de equipo: 'I designed the rollback plan' te reconoce a ti y al equipo a la vez.
- Combina un error conocido con lo que cambiaste después. Se lee como ownership, no como debilidad.
- Empieza un pedido de promoción con evidencia, y después haz el pedido explícito. Un reviewer puede estar de acuerdo con evidencia, no con un sentimiento.
La mayoría de los developers escribe una autoevaluación sólida en español y una débil en inglés. No porque el trabajo haya sido distinto, sino por el idioma. En español, la modestia y las frases vagas ('estuve trabajando en el proyecto de pagos') suenan humildes y normales. En inglés, la misma frase ('I worked on the payments project') se lee como de bajo impacto, porque describe una tarea, no un resultado.
Esta guía te da una fórmula de tres partes para describir el impacto de tu trabajo en inglés, con reescrituras reales de antes y después, más las frases para hablar de errores y pedir una promoción sin sonar inseguro.
La fórmula de tres partes para describir impacto
The three-part formula for describing impact
Una buena línea de autoevaluación tiene tres partes: qué hiciste, el resultado medible y por qué importó. La mayoría de los developers solo escribe la primera parte.
Fórmula: [qué hiciste] + [el resultado, con un número si lo tienes] + [por qué importó, si no es obvio].
Ejemplo: 'I profiled the API and found the N+1 query causing slow page loads' (qué hiciste) + 'fixing it cut average response time from 800ms to 150ms' (el resultado) + 'which removed our top customer complaint that quarter' (por qué importó).
7 reescrituras: de tarea vaga a impacto cuantificado
7 rewrites: vague task to quantified impact
En lugar de
"I worked on the payments project."
Escribe
"I led the redesign of the checkout flow, which reduced cart abandonment by 18% in the first month after launch."
Por qué funciona: Nombra tu contribución específica y un resultado de negocio medible, no solo el proyecto al que te asignaron.
En lugar de
"I helped improve performance."
Escribe
"I profiled the API and found the N+1 query causing slow page loads. Fixing it cut average response time from 800ms to 150ms."
Por qué funciona: Muestra el diagnóstico, no solo la solución, lo que demuestra criterio técnico.
En lugar de
"I did a lot of code reviews this quarter."
Escribe
"I reviewed 45 pull requests this quarter and caught three issues that would have caused production incidents, including one security vulnerability."
Por qué funciona: Un número más una consecuencia convence más que 'mucho'.
En lugar de
"I'm not sure I did that much this quarter."
Escribe
"This quarter I shipped two features, mentored one new hire, and reduced our CI build time by 30%."
Por qué funciona: Reemplaza la duda por una lista de hechos. Escribe la lista antes que el sentimiento.
En lugar de
"The team shipped the migration."
Escribe
"I was the main contributor on the database migration: I designed the rollback plan and handled the cutover with zero downtime."
Por qué funciona: Reconoce el resultado del equipo mientras nombra tu rol individual en él.
En lugar de
"I made some mistakes with the deployment process."
Escribe
"Early this quarter, I pushed a change that caused a 10-minute outage. I wrote the postmortem, added a staging gate to prevent it from happening again, and it has not recurred since."
Por qué funciona: Combina el error con la solución. Se lee como ownership, no solo como una confesión.
En lugar de
"I think I'm ready for the next level."
Escribe
"Over the past two quarters I've been operating at a senior level: owning projects end to end, unblocking teammates, and making architectural decisions without supervision. I'd like to talk about what it would take to formalize that."
Por qué funciona: Primero la evidencia, después el pedido. Un reviewer puede estar de acuerdo con evidencia; no puede estarlo con un sentimiento.
Cómo hablar de un error o un área de crecimiento
How to talk about a mistake or a growth area
Omitir un error conocido de tu autoevaluación suele salir mal si tu manager lo menciona primero. Nombrarlo tú mismo, junto con lo que cambiaste después, suele leerse como más senior, no menos.
- "I underestimated the complexity of ____, which pushed the timeline. Next time I'll scope more carefully before committing to a date."
- "My growth area this year is ____. I'm addressing it by ____."
- "I want to get stronger at ____. I've started doing ____ to work on it."
- "Looking back, I'd handle ____ differently: I'd ____ earlier instead of ____."
Cómo pedir una promoción o subir de nivel
How to ask for a promotion or leveling up
Pedir una promoción en tu autoevaluación es esperado, no una falta de respeto, siempre que esté respaldado por la evidencia que ya escribiste arriba. Empieza con la evidencia y después haz el pedido explícito.
- "Based on the scope of what I've been doing this year, I'd like to talk about what it would take to move to ____."
- "I believe my work this year has been at the ____ level. Can we talk about a formal path to that title?"
- "I've been operating beyond my current level in ____ and ____. I'd like this review to include a conversation about leveling up."
Para la conversación en vivo (no solo la autoevaluación escrita), nuestra guía de 1-1s tiene más frases para pedir una promoción y negociar el seguimiento.
Artículos relacionados
¿Listo para practicar tu inglés en el trabajo?
Lingua-e tiene ejercicios interactivos basados en conversaciones reales de developers: standups, code reviews, retrospectivas y más. Practica hasta que salga solo.
Prueba Lingua-e gratis
Escrito por
Roxana LafuenteFundadora de Lingua-e
Roxana Lafuente es ingeniera de software con más de 8 años de experiencia. Al comienzo de su carrera, aunque ya había aprobado el First Certificate in English, se bloqueaba cada vez que tenía que hablar en el standup diario. Era un problema que nadie estaba resolviendo. Después de más de 2.000 standups, descubrió qué es lo que realmente construye la fluidez: practicar situaciones que se parecen a tu trabajo real. Creó Lingua-e para que otros developers no tuvieran que tomar el camino largo para sentirse seguros trabajando en un entorno de desarrollo internacional.