> Blog post by Lokesh Saini
> Canonical (HTML): https://www.lokeshsaini.com/blog/reading-the-role-before-writing

Two roles can fit your background and still require completely different applications. A senior product designer role and a design-engineer role might both be honest matches for who you are. But the person reviewing them is not the same person, and they are not looking for the same thing. The first act of design in a job application is deciding who you are talking to.

## The Verbs Tell You What the Team Is Missing

I read job descriptions for verbs before I read them for requirements. The nouns tell you what the team does. The verbs tell you what they cannot do yet.

A description that says "define the vision," "set direction," and "bring clarity to ambiguous problems" is describing a team that has capable executors and needs someone to organize upstream of them. A description that says "ship fast," "work closely with engineering," and "get it to production" is describing a team that knows where it is going and needs someone to close the gap between design and built. Both might list Figma, both might ask for five years of experience. They are hiring for different gaps.

Reading for the gap changes which story leads. Not the story of what I have done in the abstract. The story of what I have done that maps to the gap this team has.

## Research and Judgment vs. Build and Ship

For a role that is hiring for design judgment, the story that leads is a research-and-judgment story. A time I changed the direction because the evidence pointed somewhere unexpected. A time I ran a process that gave the team a shared vocabulary they used for the next year. A time I held a position through pressure until there was a real reason to move it.

For a role that is hiring for execution and closeness to engineering, the story that leads is a build-and-ship story. A time I prototyped something in code because a static mockup could not communicate the timing. A time I sat with an engineer during sprint planning and scoped the work until implementation surprises went to zero. A time I shipped something with a constraint and a deadline and nothing else.

The underlying experience is identical in both cases. I did the same work. What changes is the camera angle: which part of the work gets the first paragraph, and which part sits in the supporting evidence.

This is not distortion. It is editing.

## The Failure Mode of One-Size-fits-All

The most common mistake I see in job applications, including ones I have written, is trying to cover all the bases at once. Lead with research depth AND production code AND system thinking AND cross-functional influence. A paragraph for everything. Nothing lands.

The problem with this approach is that it transfers the translation work to the reader. The hiring manager has to figure out which part of your experience is relevant to their situation. That is your job, not theirs. When you make the reader do the translation, you lose them to the next application in the stack.

The reader with the clearest path through your experience is the reader who keeps reading.

## Audience Empathy Is the Job

A senior product designer is hired for design judgment. Not for the ability to code, not for the ability to manage up, not for the breadth of tools they have used. Design judgment is the thing. Everything else is supporting capability.

A design engineer is hired for the ability to close the gap between a decision and a built thing. Not for research depth, not for stakeholder management, not for the ability to synthesize a year of data into a roadmap. Closing the gap is the thing.

This distinction is the same skill the job itself requires. When you design a product, you figure out who you are talking to before you start designing. You do not produce one solution that tries to serve every user equally. You make choices. You prioritize one need. You trust that a clear answer for the right user is more valuable than a vague answer for everyone.

An application is a designed artifact. The audience is a specific person with a specific gap. The craft is deciding what to put in the first paragraph and trusting that the rest will follow.

## What to Do With This

Before writing, I ask two questions. What is the gap this team is hiring for? And which story from my experience maps most directly to that gap?

The answer to the first question comes from reading the job description as a design brief. The answer to the second comes from knowing your own work well enough to select, not list. Both take some time. Neither requires inventing anything. Your experience is already there. The work is deciding which part of it to say first.