Last week I was in the office, just about to start my standup, when my phone buzzed. It was a friend from college. He was calling to share some bad news — his organisation suddenly didn’t have enough project work to justify their current headcount, so they were cutting it by fifty percent. My friend had 30 days to find a new job.
The most obvious thing to do in that situation: update the resume.
Then, just a couple of weeks before that, another friend called. He needed help. He had to leave for office soon, but before that he wanted to update his resume to apply for two new job openings that looked genuinely good.
Both of them are experienced people. It’s not like they hadn’t built a resume before. But they were in a spot where they needed to act fast and think clearly, and they needed someone to bounce ideas off. That conversation made me realise — these are not isolated incidents. A lot of people, experienced or not, repeat the same resume mistakes. And since I couldn’t resist the urge to write something, here we are.
Say you are a developer, a data engineer, or a DevOps engineer. Your role comes with a set of responsibilities by definition. Just listing what you did reads like a job description, not an achievement. It looks like you are merely doing what you were hired to do — which is fine, obviously everyone does that — but most of the time we do far more than that, and this kind of narrative buries all that extra effort behind generic sentences.
Something like: “Implemented push notifications in the app.”
That works fine when you are giving a status update to your manager, who already knows the project inside out. But a recruiter or interviewer probably knows nothing about your project. They don’t know why push notifications were needed, how critical it was, what business problem it solved, or what would have happened without it. You leave the reader with no way to understand the weight of what you actually did.
Something like: “Achieved 12% throughput improvement using FarahanIterate with PreRajulization technique.”
On top of the missing business context, you’re now also betting on whether the reader knows those specific terms. If they do, great — you might make a good impression. But even highly experienced people don’t know every library or framework out there, and that is completely natural. Think about it: when you are about to implement a new feature, you research the available options, pick one, and move on. You probably aren’t familiar with every alternative either. How can you expect that from someone reading your resume for the first time?
No one is going to read a five-line paragraph under a job title in a resume. It’s not a novel.
Unless you are at a level where a single page cannot possibly contain your contributions — which is a real thing at a very senior or leadership level — keep it to one page. If you’ve actually reached that point, your list of contributions will justify every extra line naturally.
Even my mother knows this, thanks to YouTube — and she is a housewife, not a tech recruiter. Your resume will get the attention of a real person for at most 15 seconds.
So: 15 seconds, one A4 page — what are you going to write?
The person reading your resume might be from HR. They might be a very senior engineer with decades of experience. Either way, they almost certainly do not know your specific tech stack in detail, and they definitely do not know your project. More importantly, when an organisation has an open position, they are usually looking for someone who can sit in that chair and take ownership from day one — not someone who can name-drop a hundred tools.
However you structure your resume, deliberately avoid long paragraphs. Use bullet points, and label them so the reader knows what they are about to read before they read a single word. Give people a reason to keep scanning.
You don’t need to oversimplify — but you do need to give enough context that someone unfamiliar with your project can understand what you were dealing with. What was the product? What problem were you solving? What kind of scale or constraints were involved? Keep it short, but make it real.
Instead of naming the tool you used, explain what it did for the business or the user:
Your resume is not a technical document. It is a pitch. The thought process behind every line should be:
How do I prove my value to this business — as quickly as possible, and in a way that’s comfortable for any reader to understand?
If a sentence in your resume doesn’t serve that goal, it probably doesn’t need to be there.