Emiliano Viscarra

Evals Are Expectations Written Down

Tue, 13 Oct 2026 00:00:00 GMT

You can't blame the model for missing a target you never set.

When something goes wrong in a team, the first question is usually "who dropped the ball?" In my experience the better question is "did anyone say where the ball was supposed to go?"

I've managed engineers for a long time, and I've interviewed hundreds of them. The pattern I see most often has nothing to do with talent. Accountability fails when nobody set clear expectations. People can't hit a target they can't see, and a manager who only explains the target in the performance review is grading people, and calling it management.

Now I see the same thing with AI, almost word by word.

Evals are expectations written down.

If you never defined what a good answer looks like, you don't get to be disappointed in the model. You only get to be surprised, and surprise is a bad sign for a manager and for a product.

Feedback should never be a surprise

One belief I've kept from every team I've led: feedback should never be a surprise. If someone hears for the first time in a review that their work wasn't good enough, I failed earlier, in a 1:1 that didn't happen or a conversation I avoided because it was uncomfortable.

The fix is boring. You agree on outcomes up front. A task list tells you what people were busy with; outcomes tell you if anything changed. Then you check in often enough that the gap between "what we expected" and "what happened" never gets big.

Replace "person" with "model" and the paragraph still works.

Many teams building with AI treat the model like a new hire they never onboarded. They write a prompt, look at five outputs, say "looks good", and ship. Weeks later a user finds a bad answer, and everyone stares at the model like it betrayed them. But nobody ever wrote down what it was supposed to do. There was no expectation, so there is nothing to be accountable to.

What this looks like at Peripheral

At Peripheral we build an AI adviser for investment and strategy professionals. It reads documents, emails and transcripts, and it checks what management says against outside evidence. In that kind of product, "looks good" is not a standard. An answer that sounds confident and cites nothing is worse than no answer at all.

So our expectations are specific. A claim has to come with a source. The source has to actually say what we say it says. If the evidence is thin or contradicts management, the answer should say so instead of smoothing it over. We don't hope the model picks these up on its own. We write them down and test against them.

That discipline pays off in a place people don't expect: model releases.

We route across several providers, including Anthropic, OpenAI and Google, with automatic fallback when one of them has a bad day. A new model shows up almost every week now. For us that is mostly a test run. We put the new model on our real tasks, compare it against what's in production, and it only gets traffic if it does better on the things we care about.

None of that works without evals. Without them, every new model is an argument between people with opinions. One engineer tried it on three prompts and loved it, another tried it on two and hated it, and the decision goes to whoever talks louder in the meeting. With evals, the numbers settle it.

Gut decides what to build, evidence decides if it's good

I don't want to make this sound like everything should be measured. It shouldn't, at least not at the start.

A first version of anything is mostly conviction. You don't have users, you don't have data, you have a point of view about what matters. That is your gut, and you should trust it. If you wait for evidence before building version one, you will never build version one.

But once the thing is live, and especially once there is a model under it that keeps changing, your gut stops being a good judge of quality. Mine included. I have been sure about a feature we built, and the evidence later told a different story. That's fine. That is what evidence is for.

The honest move is to know which mode you are in. Use your gut to decide what to build. Use evidence to decide if it's good. Problems start when teams mix them up: they use data to avoid making a bold call early, or they use gut feeling to approve a model swap later.

Evals are where you switch from one mode to the other. Writing them forces the conversation that the gut can skip: what exactly do we mean by "good"?

Writing your first evals as a team

You don't need a platform or a framework to start. You need an afternoon and the people who understand the work. Here is the checklist I'd use.

Pick one task, not the whole product. Choose the thing users rely on most, or the thing that scares you most when it goes wrong.
Collect 20 to 50 real examples. Real inputs from real usage, including the ugly ones. Invented examples are always too polite.
Write down what good looks like, in plain words. "Every claim has a source." "Says 'I don't know' when the documents don't cover it." If the team can't agree on the sentence, you just found your real problem.
Write down what unacceptable looks like. Often easier and more useful. Made-up citations, confident wrong numbers, ignoring the user's question.
Have a human grade the first round. Before automating anything, people should score outputs by hand. You will learn more about your product in that hour than in a week of dashboards.
Then automate what you can. Simple checks first (is there a citation, does it point to a real document), model-graded checks after, and keep spot-checking the graders.
Run them on every change. New prompt, new model, new retrieval setup. Same evals, same bar.
Add every bug to the set. When something breaks in production, it becomes an example. Your evals should get harder to pass over time.
Review them like you review goals. Every few months, ask if the expectations still match what users actually need. Expectations go stale, for people and for models.

That's it. The first version will be incomplete, and that's okay. An incomplete written expectation is still better than a complete one that only lives in someone's head.

The manager's job didn't change

When I joined Pager as the first employee and we grew the team, I learned that most problems I blamed on people were really problems with what I never made clear. It took me longer than I'd like to admit.

Building with AI is giving me the same lesson again, faster and with less patience. The models are capable. They are also not mind readers, which puts them in the same category as every engineer I've ever worked with, and as me.

So before you blame the model, write down what you expected from it. If you can't, you have your answer, and it's a good place to start.

Emi

Making 1:1s useful - The do’s and don’ts of conversations with your manager

Thu, 12 Aug 2021 00:00:00 GMT

In my previous post about writing a resume, I found myself in both sides of the table, as interviewer and interviewee and this is also the case. I’ve been doing 1:1s from both sides of the table. As a software engineer trying to find meaning to the meeting and as an engineering manager looking to get the most out of the session. If you are an Engineering Manager looking to improve your 1:1s with your team members this could help you. If you are a Software Engineer and every time your 1:1 with your manager is close to start, you feel like it is “another meeting to waste time, this will help you too.

Not all companies are the same

Obvious but very important. Not all companies and teams are the same. Reporting structure, team size and dynamics will play together and define how the relationship between an Engineering Manager and a team member is going to be. When I started my management track I was working with a team of 2 engineers and coding at the same time. As the team started to grow, I not only had to stop coding but I also needed to use tools and mechanisms to keep track of everything that was happening around. And then, 1:1s with the team became even more important.

What is a 1:1?

I will start with the opposite. A 1:1 is not a status update. The team is probably already doing some kind of "agile, so that information can be obtained in a different meeting or (even better) asynchronously. Avoid discussing how the project is going or when feature X is going to be finished.

A 1:1 is a space where the stage is for the engineer. And that person is the one who should be leading the meeting. That time should be used to ask questions, complain (always in a constructive way) and share feedback with your manager (and vice-versa).

For engineering managers, this is the perfect time to understand each individual better. Are there any urgent needs? How can you help this team member grow? Are there conflicts inside the team? What about between teams?

Regularity and duration

I tend to schedule 1:1s weekly and with a 45 mins duration. Sometimes there are not many topics and the meeting ends early and in other scenarios we even cancel on the spot if there are no topics to discuss. Some engineers told me that once every other week was perfect for them so while I was doing weekly 1:1s with some members of the team, others would prefer to leave a week in between. All options are fine as long as there’s constancy. As managers we should pay attention to open the conversation when the other person doesn't bring topics. There's always something to discuss about. Use this time wisely.

Setup and Tools

Nowadays almost all meetings happen through video conference but, in the past (and hopefully in the near future) I tend to ask the other person’s preference. A meeting room, a coffee shop, a walk in the park. I would always leave those options open and ask what the preference is. Sometimes sensitive topics are better discussed in a private environment or it could be just too cold to go outside. Mixing different options make these talks more dynamic and friendlier.

As for tools, I’ve tried different things and nothing added much value to me. I just use google docs to keep some notes. With each engineer I work with, I have a separate document that’s shared between both of us with a list of the past and upcoming sessions. I ask the other person to open the document before the 1:1 and add any topics that wants to discuss and I would do the same if I have any. If there are too many, at the beginning of the meeting we will briefly decide together which are the most important ones and focus on those first. If the outcome of that meeting ends with something that needs to be done for the following session, I would write it down there as well. It’s not fancy but it’s effective. You can do it as you talk or just at the end of the meeting (specially if you chose to do a walk in the park). Being able to keep track of topics improves the conversation flow and also can help following up with bigger arguments.

Career Development Plan

1:1s are a perfect opportunity to discuss about career development plans. I’ve been working with a simple template that I share with each individual which we discuss about at least every other session. I share it as a blank template and ask the engineer to fill it. Once completed we refine it together.

The document has 6 items:

Self assessment: Where you currently are at.
Goals: List of short and mid term goals (e.g. learn something, get a promotion, change role).
Strategies: Ideas that will help complete those goals such as completing studies, taking ownership of a task, preparing an internal talk or organizing a knowledge sharing session.
Resources: Material that can help you with your goals. This can be books, an online course, a conference you want to attend.
Timeline: Concrete timelines combining strategies and resources. (e.g. by end of this month I will finish this online course).
Achievements: Results gained during this time. This will start empty and be filled continuously.

Keeping the document up to date has several benefits:

It sets clear expectations between the manager and the team member.
Opens up the discussion on how to reach those goals. Here, the manager can fully support the engineer by suggesting resources and ways to get there..
When a goal is near to be completed, if it involved a promotion, raise or change of role it usually requires a whole internal process for approval within the company. Having a document like this makes it simpler, faster and smoother.

Manager’s Feedback

On top of everything mentioned above, 1:1s are the best opportunity for managers to provide constructive feedback and of course, the other way around. There’s nothing more frustrating as an engineer when companies do 3, 6 or 12 months performance reviews and when you sit down with your manager to see that feedback, you are surprised by it. To me, those are formalities that are not bad but should never be a surprise. If as a manager I have to point out things to improve to the other person, I must do that on the regular 1:1s and not just at the end of a quarter or year.

Chill

In the current times where most of us are working from home, there’s no “coffee break talks” so don’t forget to also use a part of the meeting time to talk about life. We, as individuals, are used to it 🎉.

Cómo escribir un CV relevante en el mundo del Software

Tue, 13 Jul 2021 00:00:00 GMT

Durante mi carrera como desarrollador de software, manager de ingeniería y co-fundador, pasé por docenas de entrevistas y también entrevisté a cientos de candidatos.

En esta breve lectura pretendo ayudarte a escribir una mejor versión de tu currículum o incluso a hacer el primero. También enumero algunas herramientas diferentes que uso o usé para crearlo. Todo esto se basa en mi experiencia personal trabajando en tres países distintos, aplicando a puestos de trabajo en la industria de la tecnología, como desarrollador junior a senior, y también cambiando varias veces mi enfoque de lo que estaba buscando. Comencemos.

No importa cuánta experiencia profesional uno tenga o cuántas veces lo haya hecho, escribir o actualizar tu propio currículum suele ser una tarea bastante tediosa. No sólo no nos gusta hacerlo sino que además nos suele agarrar desprevenidos cuando alguien nos lo pide. "Sí, ya te lo envío" y entonces ocurre lo inevitable, nos ponemos a buscar entre los archivos de nuestra computadora, luego vamos a Google Drive y por último empezamos a escribir la palabra "currículum" en nuestro cliente de correo hasta que encontramos algo que es aburrido y obviamente desactualizado. Rápidamente añadimos algo encima, revisamos las fechas y lo enviamos a la persona que nos lo pidió.

Y ese es el escenario feliz.

Durante muchos años repetí este patrón hasta que me di cuenta de que estaba perdiendo oportunidades. Oportunidades de las que no te enteras porque las consigue otra persona en lugar de tuyo. Porque el amigo de un amigo te pidió tu currículum y estabas demasiado ocupado para actualizar el anterior y luego te olvidaste. Porque el que enviaste a un “recruiter” sobre esa interesante oportunidad de trabajo era uno más del montón y como había tantas personas aplicando eligieron a otro.

En algunos casos, como responsable del proceso de contratación, revisaba más de 100 CVs al día y, como esa era una de las muchas tareas que tenía, me encontraba siempre apurado, lo que significa que revisaba rápidamente los CVs al principio de mi jornada laboral tratando de captar los que destacaban.

En otros casos tenía alguien dedicado a contratar ayudándome. El proceso suele consistir en una discusión inicial en la que se enumeran los requisitos y lo que es bueno tener, y luego esa persona hace esas primeras “pasadas” y compartía conmigo lo que considere relevante para darle un segundo vistazo.

De más esta decir que el proceso sigue siendo defectuoso. Lo iteré varias veces para intentar mejorarlo, pero la realidad es que en la mayoría de los casos tu CV se va a leer inicialmente de forma rápida y, basándose en una evaluación de no mas de 1 minuto, se marcará como "sí" o "no", así que a la hora de escribirlo estos son los posibles perfiles que van a revisarlo.

Fundamentos

Más no siempre es mejor

Un currículum vacío es tan malo como uno abarrotado. Tu experiencia, tus habilidades y tu formación son importantes, pero no se trata de la cantidad, sino de cómo la compartís y quién la va a leer.

El currículum de una sola página sigue siendo válido como regla general. Si no tenés mucha experiencia, debería ser fácil limitarse a una página, pero puede ser (y lo va a ser) más difícil con el paso de los años. Si crees que debe tener dos páginas, no pasa nada, pero recordá que los responsables de la contratación van a revisar muy rápido las solicitudes y nadie (te garantizo que nadie) va a revisar la segunda página. Tené eso en cuenta pero, no te asustes, nos vamos a enfocar primero en añadir y luego (si es necesario) en eliminar. Incluso cuando sientas que hay mucho que decir, tenés que ser capaz de centrarte en lo más importante. El objetivo del currículum es conseguir esa primera llamada, una vez que tengas eso, vas a poder entrar en detalles por lo que tu CV ya no importará mucho y sólo se utilizará como iniciador de la conversación o como guía.

¿Es mi currículum lo suficientemente lindo?

Un CV no tiene que ser lindo, tiene que ser fácil de leer. Por supuesto que hay algo de diseño en él, la fuente, su tamaño y la disposición, son importantes (más adelante hablo de esto), pero la pregunta que hay que hacer cuando lo mires es: "¿Puedo mirar esta página y obtener información rápidamente?". Preguntate esto y, si es posible, revisalo con un amigo o colega, si ellos pueden identificar rápidamente lo que estas haciendo ahora y cuál es tu principal experiencia, estás bien encaminado.

¿En qué idioma lo escribo?

Esta sección no está en el post en inglés pero es muy relevante para los que hablamos español como primer idioma. La regla es simple: si tenés un conocimiento de inglés que te permita escribirlo en ese idioma, hacelo. No hace falta que tengas una copia en español y los motivos son los siguientes:

No importa que tanto nivel de inglés tengas (oral y escrito), escribir el currículum en inglés ya muestra conocimiento en el idioma lo cuál, aunque trabajes en una empresa 100% hispanohablante, es extremadamente útil a la hora de leer documentación o integrar servicios.
Tener el CV en inglés te abre las puertas a oportunidades en el exterior.
Muchas empresas en latinoamérica tienen clientes en el exterior por lo que el conocimiento de inglés te agrega mucho valor.
Esto es fuera del foco del CV pero escribir en inglés, ya sea comentarios en el código, notas de una versión que publiques o documentación hacen que, en el caso que un proyecto crezca, no este limitado a una región y otras personas puedan participar en él.

Aún teniendo un conocimiento básico de inglés es útil que lo escribas en ese idioma, quizás con la ayuda de un amigo o colega.

En el caso de no poder hacerlo, un currículum en español sigue siendo un currículum válido y mis primeras versiones lo fueron en español. Dicho esto, los ejemplos concretos que voy a mencionar a continuación los voy a dejar en inglés para, en el caso de que estes intentando hacerlo en este idioma, te ayuden.

Estructura

Empecemos a cubrir las diferentes partes que debe tener tu currículum:

Información Personal

La primera parte del currículum debe incluir la información personal:

Nombre completo
Dirección de correo electrónico
Número de teléfono (con código de país)
Tu ubicación (ciudad y país es suficiente, no hay necesidad de usar tu dirección completa)
Opcional: Si tenés algún sitio relevante (ej. LinkedIn, GitHub o tu propia web) lo podés agregar. En el caso de que agregues algo, revisa que este actualizado. Si compartís tu perfil de GitHub, evaluá si vale la pena: tiene proyectos públicos o colaboraciones?. Si no es el caso (como me pasa a mi) no hay necesidad de incluirlo.

Recomiendo no agregar una foto ya que crea prejuicios, aunque hablo en base a mi experiencia en Argentina, Estados Unidos y Alemania. En algunos países, los responsables de la contratación esperan que tengas una foto pero si sabes que no es obligatorio no la agregues.

Experiencia Laboral

Tu experiencia laboral será la parte central de tu currículum mientras las otras secciones servirán de complemento.

Si aún no tienes experiencia laboral, no te preocupes, te enfocarás en las otras secciones.

Empezá por anotar todos los puestos en los que trabajaste en orden cronológico inverso (el actual o más reciente arriba, el primero abajo). Tal vez sea uno, tal vez sean diez, no te preocupes, si hace falta lo ajustamos mas tarde.

Nombre de la empresa
Tu rol
Período de tiempo
Ciudad y país
Descripción

Si ya trabajaste en muchos sitios, puedes empezar a excluir los que no consideres relevantes para el puesto al que aspiras. En las primeras versiones de mi currículum, cuando buscaba un trabajo como desarrollador, incluía con orgullo mi experiencia reparando PCs, pero a medida que fui ganando experiencia en empresas como programador, esto era menos relevante. Sigo estando orgulloso de mis meses abriendo cajas, conectando cables y con ese miedo a que una PC no encienda pero, cuando me presentaba a puestos para desarrollador iOS, esa información era irrelevante para los “recruiters”, por lo que la eliminé.

Nombre de la empresa

Tal vez hayas trabajado en una empresa muy conocida, o tal vez hayas trabajado en "Great Super Info Technologies Inc", o en "MycroCircuit". Tal vez pienses que la empresa es muy conocida pero alguien de otra ciudad o país puede no tener idea de ella. Es importante añadir junto al nombre de la empresa, una descripción muy breve de lo que es.

Ejemplos (más ejemplos al final del post en mi actual currículum):

Great Super Info Technologies Inc - (fin-tech startup with more than one million customers worldwide)
MycroCircuit - (circuit sharing company with focus on the latin american market)

El punto es proporcionar un contexto rápido a la persona que lee el CV, que puede no conocer el nombre de la empresa y no tomarse el tiempo de buscarlo en Google. Esta parte es muy importante si aspiras a puestos de trabajo fuera de tu país actual, una empresa que podría ser muy conocida en Argentina o Latinoamérica puede no ser popular en Europa o Norteamérica.

Rol

Si el nombre de tu rol no es tan común porque la empresa utiliza un título no convencional, añade una breve descripción o escribe el "equivalente conocido".

Ejemplos:

Junior Software Developer ✅
Senior Software Engineer ✅
DevOps ✅
Software Architect ✅
Engineering Manager ✅
Digital Overlord ❌
Lead Code Wizard ❌
Brogrammer ❌

Esto también es válido para empresas grandes como Google, Facebook y Microsoft que usan niveles internos como L4, E6 or SDE II [fuente]. Si tenés o tuviste un título así, también convertilo a algo mas universal como por ejemplo Senior Software Engineer (L5) .

Período de Tiempo

Simple, sólo el mes de inicio, el año y cuándo dejaste de trabajar. Algo como "agosto 2017 - septiembre 2020" es más que suficiente. Lo importante es mostrar cuánto tiempo trabajaste en cada lugar y pueda hacerte preguntas al respecto. Si estuviste menos de 6 meses en un lugar o si tenés espacios grandes es probable que te pregunten algo al respecto. No hay nada malo en ello, pero preparate.

Ciudad y País

No hay mucho para decir de esta parte, simplemente escribí dónde vivías durante cada trabajo. Si trabajaste a distancia, usa tu ubicación, no la de la empresa.

Descripción

Esta es la parte más importante de tu experiencia laboral y, lógicamente, la más difícil de escribir. Hay varias formas de encarar la descripción de lo que hiciste. Para mí es más que una descripción, es una lista concreta de cosas que hiciste y lo más importante el resultado que has creado.

Ese es uno de los principales elementos diferenciadores que hace que un currículum se destaque por sobre otros. Esa lista puede alargarse fácilmente y acá es donde tendrás que usar tu criterio y elegir no más de 3-4 elementos por cada lugar en el que hayas trabajado. Para ayudarte a decidir cuáles destacar, pensá en el puesto que estás buscando o al que estás por aplicar. Digamos, por ejemplo, que ayudaste (o lideraste) en el proceso de contratación de nuevos integrantes en un equipo y sabes que el puesto al que vas a aplicar está buscando ampliar el equipo. Va a llamar la atención saber que hiciste esto. Otro ejemplo, querés trabajar para una empresa muy pequeña, una empresa que empezó recientemente. Estos entornos requieren que trabajes con bastante independencia y tomes decisiones por vos mismo. Si impulsaste iniciativas en el pasado, agregalas junto con el impacto que crearon. Tal vez te diste cuenta de que vas a tener que cambiar tu currículum aunque ya esté actualizado y adaptarlo en función de a quién se lo envíes. Cada vez que estes por envíar tu CV, aún sabiendo que esta al día, revisalo y pensá que están buscando y reemplazá, agregá, quitá algunos de estos puntos para sumar reelevancia.

Mientras escribía esto busqué CVs anteriores que escribí hace muchos años. Este es un extracto de uno de 2012 que incluye mis 3 primeros trabajos como desarrollador de software:

❌ Mal ejemplo:

Company A | May 10 – Nov 11

PHP - Web Developer

Development and maintenance of Hosting Control Panel and Webmail (Edgedesk and Open-eXchange)

Company B | Aug 08 – May 10

Java - PHP Developer

Full search engine created (PHP/MySQL). Main website renewed. Developed internal applications for managing content (Java/Struts/Hibernate).

Company C | Mar 08 – Aug 08

PHP Developer

Performed Website maintenance and development, and created new modules for CMS platforms in PHP.

Terrible. Esto describe lo que hice pero no cuenta mucho. En esa época, para mi estaba bien pero ahora cuando lo leo pienso "Así que trabajaste como desarrollador web y desarrollaste cosas web, genial”.

Ese era un extracto de mi currículum hace 10 años y desde que mi enfoque principal cambió, acumulé más experiencia y ya no tengo estas empresas listadas en mi CV de una sola página ya que tuve que quitar cosas. Si tuviera que reescribirlo siguiendo las sugerencias actuales, se vería así:

✅ Versión actualizada:

Company A | May 10 – Nov 11

PHP - Web Developer

Rewrote key components of the hosting control panel improving the platform performance by 50% and decreasing the count of weekly reported bugs by 80%.

Company B | Aug 08 – May 10

Java - PHP Developer

Created a full text search engine enabling users to find articles quickly from the home page.
Developed internal applications for managing the web content which allowed content writers to publish new articles on the main website automatically.

Company C | Mar 08 – Aug 08

PHP Developer

Improved website quality by reducing tech debt and focusing on maintenance tasks.

¿Se ve la diferencia? Ambas describen lo que hice, pero la segunda versión provee mucho más contexto.

En la Compañía A añadí porcentajes y eso es bueno. Siempre que puedas usar datos concretos, hacelo. Si no era posible recopilar esa información porque no tenías acceso o no se estaba haciendo un seguimiento adecuado, intenta utilizar una estimación, pero no mientas, tené en cuenta que podrían preguntarte sobre esto, así que deberías poder explicar con más detalle qué hiciste y cómo podés medir que el rendimiento mejoró un x%. Lo importante es que intentes usar información “medible”, cosas que has hecho (como individuo o como colaborador con tu equipo) y el impacto que ha creado.

(Vas a encontrar un link a mi CV actual al final del post para ver más ejemplos sobre esto).

Educación

Recuerdo cuando escribí mi primer currículum. Estaba comenzando en la Universidad de Buenos Aires y no tenía experiencia laboral (más allá de la reparación de PCs), así que enumeré las escuelas primarias y secundarias a las que fui. Ya estaba en la universidad y, obviamente, hay que terminar el secundario para poder ir, así que esa información era completamente redundante.

Debes enforcarte en las cosas que te hacen ser mejor en el área de Software. Si todavía estás en la universidad, podés escribir el título y un estimado de cuándo se espera que lo termines. En Estados Unidos se suele agregar el GPA (“Grade Point Average” que es el resultado promedio de todas tus calificaciones calculadas en una escala de 7 puntos. Este es el estándar común en los Estados Unidos pero esto es muy puntual para universidades de ese país y en Argentina las escalas son diferentes así que nunca escribí ningún número. Incluso si pudiera calcular algo similar confundiría a los demás).

Si has hecho algún curso o capacitación presencial o en línea, agregalo también aquí.

Habilidades

Las habilidades son el apartado más amplio y, al mismo tiempo, el que más debes ajustar cada vez que envíes una solicitud. ¿Por qué? Porque listar diferentes lenguajes de programación, bases de datos, tecnologías, plataformas y hobbies, no es suficiente. Hay que adaptar esta parte en función del puesto de trabajo al que te presentas. No te olvides que los “recruiters” pueden no tener experiencia en tecnología y que quizás estén siguiendo instrucciones que otra persona les dió.

Comienza añadiendo los idiomas que hablas y su nivel: nativo, fluido, intermedio, etc.
Añade los principales lenguajes de programación con los que has trabajado y te interesan (si has trabajado con PHP hace más de 5 años y no buscas trabajo como desarrollador PHP no es necesario que lo tengas ahí).
¿Bases de datos? ¿Plataformas?

Al momento de enumerar las tecnologías, los lenguajes de programación y las plataformas, agregá primero las más importantes y agrupalas de forma coherente. No añadas un sistema de clasificación, estrellas o barras de progreso. He visto innumerables CVs con calificaciones como "Swift 9/10" o "Kotlin ⭐️⭐️⭐️⭐️". ¿Significa esto que eres muy muy bueno en Swift y perfecto con Kotlin? No existe tal cosa. Dejá que eso se vea en la descripción de tu experiencia laboral.

Podés añadir todas las cosas que quieras, pero mantené la coherencia y evita la redundancia. ¿Tenés experiencia con Objective-C o Swift? Genial, entonces no es necesario poner Xcode en la lista ya que es obvio que lo has utilizado.

❌ Evitá algo como esto:

Swift, Xcode, AWS, MySQL, Javascript, Azure, .NET, GraphQL, Python, MongoDB

✅ Intentá reorganizar:

Swift, Javascript, .NET, Python | MySQL, MongoDB, GraphQL | AWS, Azure

Proyectos y Méritos (opcional)

Esta sección es una oportunidad para agregar links a proyectos que hayas creado y que no formen parte de empresas en las que hayas trabajado. ¿Hiciste una aplicación? Añade una breve descripción y un link a la misma. Tal vez participaste en un hackathon y ganaste. Describe lo que construiste y en el caso de haber recibido un premio, cuál fue. Si te ofreciste como voluntario para organizar un evento, también podés agregarlo acá.

Fase de revisión

Lo lograste! 💪. Ya tenés la primera o nueva versión de tu CV. Lo más importante ahora es buscar errores tipográficos. Léelo varias veces y, si podés, pedile a otra persona que también lo haga. No es bueno para el medio ambiente, pero imprimirlo ayudará a encontrar cualquier error tipográfico.

Ahora es el momento de refinarlo. El primer paso es intentar que sea una sola página, si aún no lo es. Preguntate lo siguiente:

¿Tengo información redundante?
¿Hay información que no es tan relevante como otra?
¿A quién le quiero enviar este CV? ¿Está el contenido adaptado a eso?

Cada vez que leo mi propio CV hago cambios. Tal vez algo que no suena del todo bien o una pequeña edición. Tu currículum evoluciona con el tiempo y con cada lectura.

Herramientas

Hay muchas herramientas que se pueden usar para crear o añadir tu currículum. En cuanto busques en Google “resume template“ o “resume creator” encontrarás una cantidad de resultados abrumadora. Y no sólo eso, muchas herramientas te cobran por crear un CV de aspecto decente. Muchas veces nos encontramos en una dicotomía y decidir si usar o no alguna de estas herramientas, es un asunto complejo. Aquí están las que yo uso o usé, me ayudaron y, todas son gratuitas:

LinkedIn es una gran herramienta para hacer crecer tu red profesional. Muchos “recruiters” utilizan la plataforma como una forma de llegar a los potenciales candidatos. También te da la oportunidad de ver lo que buscan las empresas y postularte desde ahí.

Personalmente recomiendo tener tu propio currículum en PDF pero también mantener una copia muy similar en LinkedIn, ya que mejorará tu exposición. A mí me contactan en el 90% de los casos a través del chat de LinkedIn pero en su mayoría, luego de una breve charla, me piden que les envíe una versión en PDF de mi CV, así que no confíes sólo en LinkedIn. Aunque la plataforma tenga una función para exportar un PDF, es mala y la información no está tan bien organizada.

Google Docs

Durante varios años usé Google Docs para crear mi CV. Hay algunos “templates" que no son geniales pero sí un buen comienzo. Por otro lado, es fácil a la hora de añadir rápidamente tu información y tener algo decente y constantemente actualizado. Cuando lo usaba con este fin, cada vez que tuve que actualizar mi currículum, pude encontrarlo rápidamente. Además, te da la posibilidad de compartirlo online con otras personas que pueden revisarlo rápidamente y añadirle comentarios antes de tener tu versión final.

resumake.io

Hace unos meses empecé a buscar de nuevo formas de crear un currículum fuera de lo que usaba habitualmente (Google Docs) y me encontré con esta herramienta de uso gratuito.

Resumake es un sitio web para generar automáticamente CVs en LaTeX sin necesidad de escribir ningún código TeX. Te permite crear rápidamente tu currículum basándote en unas plantillas predeterminadas que luego se pueden exportar como PDF, Latex o JSON (exportarlo como JSON sirve como copia de seguridad que luego podés volver a subir a la web para seguir editando tu currículum ya que no tiene almacenamiento en la nube como Google Docs). La experiencia es rápida y podes elegir las diferentes opciones de plantillas que son todas muy simples (en el buen sentido de la palabra). Tiene secciones para añadir tu perfil, trabajo, educación, habilidades, proyectos y premios. Esto es lo que estoy utilizando ahora y ya lo he recomendado a amigos que han quedado muy contentos. Incluso si estás fuera del área de software se pueden adaptar las categorías como Proyectos y Premios en algo más ya que es personalizable.
Podés encontrar el código fuente aqui y es totalmente gratis de usar.

Me contacté con el creador de resumake, Saad Quadri, quien me mencionó brevemente que tiene previsto lanzar una nueva versión (v3) en los próximos 1-2 meses y que el sitio seguirá siendo gratuito y de código abierto para siempre (si encuentras la herramienta útil y querés apoyarlar se puede donar haciendo clic en “Donate” en el pie de su página web).

Último Tramo

Independientemente de la herramienta que utilices, exporta el currículum de forma amigable y no editable (el PDF funciona perfectamente) y utiliza un nombre que sea fácil de encontrar y que además te identifique (ej. Emiliano-Viscarra-Resume.pdf )

Si lo querés como referencia o ejemplo, podes descargar el mío acá

Además, no olvides crear un perfil de LinkedIn con toda la información de tu nuevo currículum o, si ya tenés uno, asegúrate de que esté actualizado 🚀.

Este es mi primer post y mi idea es escribir más sobre temas relevantes relacionados con “Engineering management”, cultura en empresas de software y otros. Si te resultó útil este post, tenés preguntas o querés que profundice en algunas de las cosas mencionadas anteriormente, podés escribirme un mail o encontrarme en LinkedIn, Twitter o Instagram.

Writing a Relevant Resume in the Engineering World

Tue, 13 Jul 2021 00:00:00 GMT

During my career as a Software Developer, Engineering Manager and Co-Founder I went through dozens of interviews and I also interviewed hundreds of candidates.

In this short read I aim to help you write a better version of your resume or even make your first. I also list some different tools I use or used to create it. Everything here is based on my personal experience working in three different countries, applying to jobs in the tech industry, from junior to senior developer, and also switching my focus of what I was looking for. Let’s begin.

It does not matter how much professional experience one has or how many times you’ve done it, writing or updating your own resume is usually a painful task. Not only we don’t like doing it but also we are usually caught off-guard when someone else asks us for it. “Yes, I’ll send it to you right away” and then the inevitable happens, we rush into our computer files, then we go to Google Drive and lastly we start writing the word “resume” in our email provider until we find something which looks dull and obviously outdated. We quickly add something on top, review the dates and send it to the person who asked for it.

And that’s the happy scenario.

For many years I repeated this pattern until I realized I was missing opportunities. Opportunities you don’t know about because someone else gets them instead of you. Because a friend of a friend asked for your resume and you were too busy to update your old one and then forgot about it. Because the one you sent to a recruiter about that interesting job opportunity was just one more in the pile and since there were so many applicants they picked somebody else.

In some scenarios, as a hiring manager, I was reviewing more than 100 resumes per day and since that was just one of the many duties I had, I found myself always in a rush which means that I was checking resumes quickly at the beginning of my day trying to catch the ones that stood out.

In other circumstances I had a recruiter helping me. The process usually consists of an initial sync listing the requirements and nice to haves, and then the recruiter will be doing those first passes and sharing what they consider relevant with me to take a second look.

The process is still flawed. I iterated several times trying to improve it but the reality is that in most cases your resume will be initially read quickly and based on a 1 min assessment flagged as a "yes" or "no” so this is the audience you are aiming to.

The Basics

More is not always better

An empty resume is as bad as an overcrowded one. Your experience, skills and education are important but it’s not about quantity, it’s about how you share it and who is going to read it.

The single page resume is still valid as a rule of thumb. If you don’t have a lot of experience, it should be easy to stick to one page but it can (and will) get trickier as years go by. If you feel that you must have two pages that's fine but remember, hiring managers will be quickly reviewing applications and no one (I can guarantee you, no one) will check the second page. Keep this in mind but don’t panic, we will focus first on adding and then (if necessary) deleting. Even when you feel you have a lot to say, you have to be able to focus on what's most important. The goal of the resume is to get that first call, once you have that, you will be able to go into details so your resume will not matter much anymore and it will just be used as a conversation starter or guide.

Is my resume pretty enough?

Resumes don’t have to be pretty, resumes have to be easy to read. Of course there's some design into it, the font, its size and the layout are important (more on this later) but the question you have to ask when you look at it is: “Can I look at this page and get the information quickly?”. Ask that question yourself and check with a friend or colleague, if one can rapidly identify what you are doing now and what's your main expertise you are on the right track.

Structure

Ok so let’s start covering the different parts your resume should have:

Personal Information

The first part of your resume should include your basic info:

Name
Email address
Phone number
Your location (city and country is enough, there’s no need to share your personal address)
Optional: If you have a link that’s relevant about you (e.g. LinkedIn, GitHub or your own website) add it as well. Whatever you add make sure it’s updated. As for sharing your Github profile, ask yourself if it’s worth sharing: do you have public projects?. If you don’t (like me) there’s no need to add it.

I recommend not adding a photo since it creates bias although I’m speaking based on my experience in Argentina, United States and Germany. In some countries, hiring managers expect you to have a picture but if you know it’s not mandatory don’t add it.

Adding your work experience

Your work experience will be the core part of your resume and you will complement this with the other sections.

If you don’t have work experience yet, don’t worry, you will focus on the other sections then.

Start by writing down all the places you worked on in reverse chronological order (current or most recent job on top, first on the bottom). Maybe it’s one, maybe it’s ten, don’t worry, we will refine it later.

Company name
Your role
The time period
City and country
Description

If you already worked in a lot of places, you can already start excluding the ones that you don’t consider relevant for the position you are aiming to. In the first versions of my resume, when I was looking for a job as a software engineer, I proudly included my experience repairing and assembling computers, but the more places I worked on, the less relevant this became. I’m still proud of my months opening boxes, connecting cables and with that fear that a computer won’t turn on but, when I was applying for iOS Developer roles, that information was irrelevant for the recruiters therefore I removed it.

Company name

Maybe you worked in a well known company or maybe you worked at “Great Super Info Technologies Inc”, or what about “MycroCircuit”? Maybe you think the company is well known but someone from another city or country has no idea about it. Complement the company name with a very short description of what the company is.

For example:

Great Super Info Technologies Inc - (fin-tech startup with more than one million customers worldwide)
MycroCircuit - (circuit sharing company with focus on the latin american market)

The point here is to provide a quick context to the person reading the resume who may not know the name of the company and may not take the time to google it. Pay a lot of attention to this part if you are aiming to apply to jobs outside your current country, a company that could be well known in Argentina or Latin America may not be popular in Europe or North America.

Role

If your role is not that common because the company uses a non-conventional title, add a brief description or write the “known equivalent”.

Examples:

Junior Software Developer ✅
Senior Software Engineer ✅
DevOps ✅
Software Architect ✅
Engineering Manager ✅
Digital Overlord ❌
Lead Code Wizard ❌
Brogrammer ❌

This also applies to big companies like Google, Facebook and Microsoft who use their own sub levels like L4, E6 or SDE II [source]. If you have or had a title like this, also translate it to a friendlier version. Something like Senior Software Engineer (L5) .

Time Period

Keep it simple, just write the start month, year and when you stopped working there. Something like “Aug 2017 - Sep 2020” is more than enough. People will want to know how long you worked at each place and may ask you questions if you stayed less than 6 months in a place or you have big gaps. There’s nothing wrong with that but be prepared.

City and Country

Not much to add here, just write where you were located for each job. If you were working remotely add your location not the company one.

Description

This is the most important part of your work experience and logically the hardest to write. There are several ways to approach describing what you have done. To me is more than that, it’s a concrete list of things you did and most important the outcome that you created.

That’s one of the main key differentiators of what makes a resume stand out. That list could get long easily and here’s where you will have to use your criteria and pick no more than 3-4 items for each place you worked at. To help you decide which ones to highlight, think about the position you are looking for or about to apply. Let’s say for example that you helped (or lead) the process of hiring new members in a team and you know that the position you are going to apply is looking to expand their team. It will catch their attention to know you did this. Another example, you want to work for a very small company, a company that’s recently started. These environments require you to self manage and make decisions on your own. If you drove initiatives in the past, add them there and the impact that it created. By now you may have realized that you should change your resume even if it’s already up to date and adapt it depending on who you are sending it to.

While writing this I looked for previous resumes I wrote in the past. Here’s an extract of one from 2012 including my first 3 jobs as a Software Developer:

❌ Bad example:

Company A | May 10 – Nov 11

PHP - Web Developer

Development and maintenance of Hosting Control Panel and Webmail (Edgedesk and Open-eXchange)

Company B | Aug 08 – May 10

Java - PHP Developer

Full search engine created (PHP/MySQL). Main website renewed. Developed internal applications for managing content (Java/Struts/Hibernate).

Company C | Mar 08 – Aug 08

PHP Developer

Performed Website maintenance and development, and created new modules for CMS platforms in PHP.

Terrible. This describes what I’ve done but doesn’t tell much. Back then it made total sense for me but now when I read it I think “So you worked as a web developer and you developed web things, great”.

That was a extract of my resume 10 years ago and since my main focus changed and I accumulated more experience I don’t have these companies listed in my single page resume as I had to remove things but if I had to rewrite it following what I do now, it would look like this:

✅ Better example:

Company A | May 10 – Nov 11

PHP - Web Developer

Rewrote key components of the hosting control panel improving the platform performance by 50% and decreasing the count of weekly reported bugs by 80%.

Company B | Aug 08 – May 10

Java - PHP Developer

Created a full text search engine enabling users to find articles quickly from the home page.
Developed internal applications for managing the web content which allowed content writers to publish new articles on the main website automatically.

Company C | Mar 08 – Aug 08

PHP Developer

Improved website quality by reducing tech debt and focusing on maintenance tasks.

See the difference? Both describe what I’ve done in those companies but the latter gives you way more context.

In Company A I’ve added percentages and that’s good. Whenever you can add concrete data, do it. If you were not able to collect that information because you didn’t have access or it wasn’t being properly tracked try to use an estimate, but don’t lie, keep in mind that you could get asked about this so you should be able to explain more in detail what have you done and how you were able to measure that the performance improved by x%. What’s important here is that you are offering measurable information, things you’ve done (as an individual or as a collaborator with your team) and the impact that it created.

(You can find a link to my current resume at the end of the post to see more examples about this).

Education

I remember when I wrote my first resume. I was in college and without work experience so I listed the elementary and high schools I went to. I was already in college and obviously you must finish high school in order to do that so that information was completely useless and redundant.

Your focus should be around things that make you a better engineer. If you are still in college, you can write the degree and when it’s expected for you to finish. If you finished it and you had a good GPA, include it. If you don’t have a good one or don’t know what I’m talking about don’t add it. (GPA stands for Grade Point Average which is the average result of all your grades calculated on a 7-point scale. This is the common standard in the U.S. but for me this was completely new and in Argentina the scales are different so I never wrote any numbers. Even if I could calculate something similar it would confuse others).

If you took any courses, in person or online add them here as well.

Skills

Skills is the broadest section and at the same time the one you should adjust the most each time you are sending an application. Why? Because throwing different programming languages, databases, technologies, platforms and hobbies will not cut it. You have to adapt this part based on the job you are applying for. Remember, recruiters may not have tech experience and will be following guidelines that a hiring manager shared with them.

Start by adding the languages you speak and its level: native, fluent, intermediate, etc.
Add the main programming languages you’ve worked with and you care about (if you worked with PHP more than 5 years ago and you are not looking for a job as a PHP developer there’s no need to have it there).
Databases? Platforms?

When listing technologies, programming languages and platforms, put the more important ones first and group them coherently. Do not add a rating system, stars or progress bars. I’ve seen countless resumes with ratings such as “Swift 9/10” or “Kotlin ⭐️⭐️⭐️⭐️⭐️”. Does this mean you are very very good in Swift and perfect with Kotlin? There's no such thing. Let your work experience show that.

You can add as many things as you want here but keep consistency and avoid redundancy. Do you have experience with Objective-C or Swift? Great, so there’s no need to put Xcode in the list as it’s obvious you used it.

❌ Avoid something like:

Swift, Xcode, AWS, MySQL, Javascript, Azure, .NET, GraphQL, Python, MongoDB

✅ Try to reorganize:

Swift, Javascript, .NET, Python | MySQL, MongoDB, GraphQL | AWS, Azure

Projects and Awards (optional)

This section is an opportunity to link projects that you created and are not part of companies you worked at. Did you build an app? Add a brief description and a link to it. Maybe you participated in a hackathon and won. Describe what you built and what was the reward you got. If you volunteered to organize an event you can also add it.

Review phase

You made it 💪. You have your first or a new version of your resume. The most important part now is to look for typos. Read it several times and, if you can, ask someone else to also do it. Not great for the environment but printing it will help to find any typos.

Then it’s time to groom it. First step is to try to make it a single page if it’s not yet. Ask yourself the following questions:

Do I have any redundant information?
Is there anything I consider not very relevant?
Who am I sending this resume to? Is the content tailored for it?

Every time I read my own resume I make changes. Maybe something that doesn’t sound good or a small edition or deletion. Your resume evolves with time and each read.

Tools

There are tons of tools out there where you can create or add your resume. As soon as you google “resume template” you will find so many things that it’s overwhelming. Not only that, a lot of tools charge you to create a decent looking resume. It’s tricky because you may be looking for a job at this point and you have to deal with paying for something you are not sure is gonna help you. Here are the ones I use or used and helped me:

LinkedIn is a great tool to grow your professional network. Many recruiters use the platform as a way to reach potential candidates. It also gives you the chance to see what companies are looking for and apply right from there.

I personally recommend to have your own PDF resume but to also keep a very similar copy in LinkedIn since it will improve your exposure. I was approached several times by recruiters who after a brief chat on LinkedIn they asked me to send them a PDF version of my resume so don’t rely only on LinkedIn even if the platform has a feature to export a PDF it looks bad and the information is not that well organized.

Google Docs

For several years I’ve been using Google Docs to create my resume. There are a few templates that are not great but an ok start. On the other hand, you can quickly add your information there and have something decent and constantly updated. I’ve used it for many years and every time I had to update my resume I was able to find it quickly. It also gives you the possibility to share it online with other people who can quickly review and add comments into it before you have your final version.

resumake.io

A few months ago I started looking again for ways to create a resume outside of what I was using regularly (Google Docs) and I stepped into this great and free to use tool.

Resumake is a website for automatically generating elegant LaTeX resumes without the need to write any TeX code yourself. It allows you to quickly create your resume based on a few predetermined templates which you can export as a PDF, Latex or JSON (exporting it as JSON serves as a backup that you can later upload in the website to continue editing your resume). The experience is fast and you can pick the different templates options which are all very clean. You have different sections to add your profile, work, education, skills, projects and awards. This is what I’ve recently used and I’ve already recommended it to friends who were very satisfied by it. Even outside engineering you can adapt the categories like Projects and Awards into something else since it’s customizable. You can find the source code here and it’s totally free to use.

I’ve contacted the creator of resumake Saad Quadri who mentioned that he is planning to release a new version (v3) within the next 1-2 months and that the site will continue to be free + open source forever (so if you find the tool useful and want to support it you can donate by clicking on Donate on his website footer).

Final Stretch

No matter which tool you use, export the resume in a friendly and non-editable way (PDF works perfectly fine) and use a name that’s easy to find and also identifies you (e.g. Emiliano-Viscarra-Resume.pdf )

If you want to use it as reference you can download my resume here

Also, don’t forget to create a LinkedIn profile with all the information you have on your resume or, if you already have one, make sure it’s up to date 🚀.

This is my first post and I’m planning on writing more about relevant topics including engineering management, culture and more. If you found this post useful, have questions or want me to go deeper on some of the things mentioned above, you can write me an email, or find me on LinkedIn, Twitter or Instagram.