To read this blog in English, click here.
“Responsible for developing scalable cloud applications using AWS.”
Esa frase no me dice nada, no porque esté mal escrita, sino porque podría pegarla en cien hojas de vida distintas y encajaría igual de bien en todas. Cada semana leo líneas así de candidatos que claramente construyeron cosas reales, y cada semana esas cosas reales se quedan invisibles detrás de una descripción de cargo.
Esto es exactamente lo que pasa por mi cabeza la primera vez que abro una hoja de vida. No la versión pulida que te contaría en una entrevista. La real.
Presiona play aquí abajo y compruébalo por ti mismo.
Preguntas frecuentes
¿Por qué no basta con decir que construí “aplicaciones escalables”?
Un candidato escribe “responsible for developing scalable cloud applications using AWS.” No dudo que hizo el trabajo. Dudo que yo pueda saber cuál fue ese trabajo.
Ahora mira la reescritura. “Designed and deployed an event-driven AWS platform using AWS Lambda, Amazon SQS, and Amazon DynamoDB, processing more than 3 million events daily.” Mismo candidato, mismo proyecto, hoja de vida completamente distinta. Ya sé el patrón de arquitectura. Ya sé la escala. Ya sé qué servicios de AWS usó de verdad y cómo encajan entre sí. Una frase me obligaba a adivinar. La otra construyó el caso.
¿Basta con enumerar las herramientas que domino, como Python, AWS o Kubernetes?
Python, Java, AWS, Azure, Kubernetes, Terraform, Kafka, Amazon Bedrock, LangChain. Suena impresionante. También me dice casi nada, porque una lista de herramientas sin un problema al lado es solo una hoja de vida disfrazándose de currículum sólido. Cualquiera puede nombrar la tecnología. Muy pocos pueden explicar la decisión detrás de ella.
¿Cómo debo describir mi experiencia con inteligencia artificial?
Ese trabajo hoy aparece en todas las hojas de vida. “Built an AI-powered chatbot using RAG and LLMs” me llama la atención por unos dos segundos, hasta que necesito la siguiente frase. ¿Qué problema resolvía, qué modelos usó, y cómo sabía que estaba funcionando? Guardrails y observabilidad dejan de ser palabras de moda cuando puedes señalar el momento exacto en que importaron. Ahí está la diferencia entre un candidato que desplegó algo real y uno que vio un tutorial.
¿Cómo debo presentar mi experiencia liderando con clientes?
“Led technical discovery sessions with US enterprise clients and translated business requirements into AWS architecture decisions” es una línea fuerte, y lo digo en serio. El trabajo con clientes combinado con criterio de arquitectura es justo lo que necesitan los roles senior. Pero pesa más al lado de una construcción concreta, no en lugar de ella. Muéstrame que puedes sentarte frente a un cliente, y luego muéstrame qué entregaste después de esa reunión.
¿Cuál es la diferencia entre describir una responsabilidad y demostrar un impacto?
Esta es la que enmarcaría. “Improved application performance” contra “reduced API latency by 40%.” “Built a data pipeline” contra “built a pipeline processing 10 million records daily.” Mismo trabajo, treinta segundos de diferencia, y ya sé cuál candidato recibe la llamada.
Una responsabilidad me dice qué te asignaron. Un impacto me dice qué cambió porque tú apareciste. No busco adjetivos. Busco el número que solo existe porque hiciste el trabajo.
¿Debo incluir habilidades blandas como “apasionado” o “buen trabajo en equipo”?
“Passionate about technology, results-driven, professional, excellent team player.” Probablemente todo cierto, y también cierto en cada hoja de vida de la pila. Tu carácter nunca fue la pregunta. La diferenciación sí, y esta línea no tiene ninguna.
¿Qué debo revisar antes de enviar mi hoja de vida?
¿Qué construiste realmente? ¿Cuál era el alcance, y para quién era? ¿Qué número cambió por tu trabajo, y puedes defenderlo en una entrevista? Si un reclutador sin formación técnica leyera esta línea, ¿se iría con una imagen clara de lo que hiciste, o con una lista de cosas que sabes?
En resumen, ¿qué es lo que realmente buscan al leer mi hoja de vida?
Treinta segundos es todo lo que tiene una hoja de vida antes de que yo decida si sigo leyendo. Gástalos en lo que construiste, en lo que logró a escala, y en lo que cambió porque tú fuiste quien lo hizo. Esa es la hoja de vida que se lee dos veces.
Ya sabes qué contar. Ven a contárnoslo.
Si eres un ingeniero construyendo cosas que valen la pena contar, tenemos un lugar para esa historia. Explora las vacantes abiertas en Robots & Pencils y muéstranos qué construiste.
English Version
You Have Thirty Seconds. Make Them Count.
“Responsible for developing scalable cloud applications using AWS.”
That sentence tells me nothing, not because it’s wrong, but because I could paste it into a hundred other resumes and it would still fit. Every week I read lines like this from candidates who have clearly built real things, and every week those real things stay invisible behind a job description.
Here’s exactly what runs through my head the first time I open one. Not the polished version I’d give in an interview debrief. The real one.
Press play below and see it for yourself.
Frequently asked questions
Why isn’t it enough to say I built “scalable applications”?
A candidate writes “responsible for developing scalable cloud applications using AWS.” I don’t doubt they did the work. I doubt I can tell what the work was.
Now look at the rewrite. “Designed and deployed an event-driven AWS platform using AWS Lambda, Amazon SQS, and Amazon DynamoDB, processing more than 3 million events daily.” Same candidate, same project, completely different resume. I know the architecture pattern. I know the scale. I know which AWS services they actually touched and how those services fit together. One sentence made me guess. The other made the case.
Is it enough to list the tools I know, like Python, AWS, or Kubernetes?
Python, Java, AWS, Azure, Kubernetes, Terraform, Kafka, Amazon Bedrock, LangChain. Impressive lineup. It also tells me almost nothing, because a list of tools without a problem attached is just a resume playing dress-up. Anyone can name the technology. Fewer people can explain the decision behind it.
How should I describe my AI experience?
That work is everywhere on resumes right now. “Built an AI-powered chatbot using RAG and LLMs” gets my attention for about two seconds before I need the next sentence. What problem did it solve, which models did you use, and how did you know it was working? Guardrails and observability aren’t buzzwords when you can point to the moment they mattered. They’re the difference between a candidate who deployed something real and one who watched a tutorial.
How should I present my experience leading client work?
“Led technical discovery sessions with US enterprise clients and translated business requirements into AWS architecture decisions” is a strong line, and I mean that. Client-facing work paired with architectural judgment is exactly what senior roles need. But it lands harder next to a concrete build, not instead of one. Show me you can sit across the table from a client, and then show me what you delivered after that meeting.
What’s the difference between describing a responsibility and demonstrating impact?
This is the one I’d put in a frame. “Improved application performance” versus “reduced API latency by 40%.” “Built a data pipeline” versus “built a pipeline processing 10 million records daily.” Same work, thirty seconds apart, and I already know which candidate gets the callback.
A responsibility tells me what you were assigned. An impact tells me what changed because you showed up. I’m not looking for adjectives. I’m looking for the number that only exists because you did the work.
Should I include soft skills like “passionate” or “team player”?
“Passionate about technology, results-driven, professional, excellent team player.” All true, probably, and all true of everyone else’s resume in the stack too. Your character was never the question. Differentiation is, and this line doesn’t have any.
What should I check before I send my resume?
What did you actually build? What was the scope, and who was it for? What number changed because of your work, and can you defend it in an interview? If a recruiter with no technical background read this line, would they walk away with a picture of what you did, or a list of things you know?
So what are you really looking for when you read my resume?
Thirty seconds is all a resume gets before I decide whether to keep reading. Spend them on what you built, what it did at scale, and what changed because you’re the one who did it. That’s the resume that gets read twice.
You know what to tell us. Come tell us.
If you’re an engineer building things worth writing about, we have a place for that story. Explore open roles at Robots & Pencils and show us what you built.
