When an international recruiter recently asked for my CV, I instinctively started writing it the way many developers do:
- A chronological list of companies,
- Programming languages, frameworks,
- Technical achievements.
Then it hit me. I wasn't writing this document for a senior engineer. I was writing it for the recruiter sitting between me and the interview. If the first person reading my CV couldn't immediately understand the value I brought, I might never reach the technical interview at all.
Knowing the Receivers
So I rewrote it from a different perspective. Instead of simply listing technologies, I described the business context behind my work.
- 10,000+ emails sent a day (in addition to "Using AWS SES/SQS")
- 800+ restaurants / POS everyday (in additional "optimised SQL speed").
- Cut down waste to 1.3% from 10 ~ 15%
- Critical updates often in 24 hours.
- Increased revenue, reduced costs, improved reliability
- Helped onboarded new clients
I still included the languages and frameworks I used, so the CTO can understand, but they became supporting evidence rather than the headline. I also highlighted the moments that demonstrated trust:
- Delivering critical business updates under tight deadlines,
- Resolving high-priority production issues,
- Taking responsibility for systems the business depended on, and
- Taking initiatives to write a mobile app using my own time.
That small shift completely changed how I viewed a CV. It's not a journal of everything I've done, and it's not a technical specification. Its job is to communicate your value clearly to the person reading it, and that person is often a recruiter before it's ever seen by an engineering manager.
One lesson I keep coming back to is this:
Write for my audience.
Outcome (for now)
After reviewing the rewritten CV, the recruiter was confident enough to forward it to Tata Consultancy Services for a role. Whether or not that particular opportunity works out, it reinforced an important lesson for me: recruiters need to understand your business impact before an engineering manager can appreciate your technical depth.
Sometimes the biggest improvement isn't gaining another skill—it's learning to communicate the value of the skills you already have.
Top comments (0)