I think many people make job search harder than it has to be.

Not because it is easy. It is not. Job search is a strange mix of research, sales, self-awareness, timing, randomness and tiny forms that all want your CV in a slightly different way.

But because it quickly becomes an emotion-driven activity:

  • Do I feel like doing it today?
  • Does this role feel right?
  • Is my CV good enough?
  • Why has nobody replied?
  • Should I change my whole profile at 23:41?

That is understandable.

It is just not a very good operating model.

So I started treating my job search more like a small delivery system.

Not coldly. Not cynically. Just with more structure.

First Problem: Too Many Open Loops

A job search creates more open loops than you expect.

There are roles to evaluate. CVs to tailor. Applications to send. Recruiters to contact. LinkedIn profiles to update. Interviews to prepare for. Follow-ups that must not be forgotten. Rejections that need to be handled without redesigning your whole personality every time.

If all of that lives in your head, it quickly becomes noise.

And noise feels like poor confidence, even when the real problem is missing system design.

I know that from software work:

When nobody knows what is deployed, what is failing, who owns what, and which change comes next, the system feels chaotic.

Job search is not that different.

I Made A Backlog

The first useful step was making the roles concrete.

Not just:

I am looking for something in DevOps.

But:

  • Which roles are strongest?
  • Which are platform/DevOps roles?
  • Which are senior backend roles with platform responsibility?
  • Which are backup volume?
  • What is the status?
  • What is the next action?
  • When should I follow up?

It sounds basic.

That is the point.

A good job search does not have to begin with polished personal branding. It can begin with a table.

I ended up splitting roles into tracks:

  • platform and DevOps
  • senior backend with operations and reliability
  • SRE and observability
  • AI/platform-adjacent roles
  • lower-priority backup roles

That made it easier to say no to roles that were only interesting because they existed.

It also made the CV work more honest. I did not need to invent a new person for every application. I only needed to highlight the part of my profile that actually fit.

Positioning Is Not Decoration

I have a senior software engineering background and have recently worked closer to DevOps, infrastructure, CI/CD, test environments, monitoring, troubleshooting and documentation.

That combination can be explained in many ways.

Bad version:

I can do a bit of everything.

Better version:

I can build software, but I also think about deployment, operations, observability, documentation and developer experience.

That is the difference between a skill list and a direction.

For me, the public version became something like:

Senior software engineer with practical DevOps and platform experience who wants to work on systems teams can actually operate.

It is not a perfect slogan. Thankfully.

But it is useful because it helps filter:

  • Roles with platform responsibility fit.
  • Senior backend roles with reliability fit.
  • Pure frontend product roles without operations fit less well.
  • Pure management roles without hands-on technical work fit less well.

Positioning is not decoration. It is a filter.

Each Role Got A Small Playbook

The next step was to stop starting from scratch every time.

For the most relevant roles, I made a short note with:

  • why the role fits
  • which part of the CV should be emphasized
  • which application text can be reused
  • which interview questions are likely
  • which questions I should ask
  • when to follow up

That is very close to what I would do for a technical system:

  • What is the context?
  • What are the dependencies?
  • What is the next safe action?
  • What should we be able to explain afterwards?

It does not remove uncertainty.

But it makes the uncertainty less foggy.

Interview Stories Should Be Reusable

One of the most important things was building a small story bank.

Not a novel.

Just short, usable stories:

  • one about production troubleshooting and observability
  • one about test environments and deployment workflows
  • one about senior review and security thinking
  • one about AI-assisted documentation and knowledge management
  • one about a mistake and what I learned from it

That helps because interviews rarely reward the person who has the most experience stored in their head.

They reward the person who can find the right experience quickly and explain it clearly.

That is also a DevOps thing:

If the runbook has to be written during the incident, it is already late.

If the interview story has to be discovered while someone asks “can you give an example?”, the answer often becomes longer, more nervous and less precise.

Follow-Up Is Part Of The System

I do not particularly enjoy follow-ups.

They can quickly feel like knocking on a door when you do not know whether anyone is home, or whether the house exists.

But without follow-up, job search becomes strangely passive.

So I set a simple rule:

After about five business days without a reply, a short polite follow-up is reasonable, unless the process clearly says otherwise.

Not a novel.

Not:

I am writing for the third time to reaffirm my deep passion for your transformative journey.

Just:

I just wanted to briefly follow up on my application. The role fits well with my experience in senior software engineering, DevOps, CI/CD, observability and platform work. I would be happy to have a short conversation if my profile is relevant.

That is enough.

AI Helped, But It Was Not Allowed To Take Over

I used AI a lot in the process.

Not to invent myself.

To structure the work.

AI was useful for:

  • comparing job ads with my profile
  • creating first drafts of CV variants
  • making application text shorter
  • finding gaps in positioning
  • building interview questions
  • turning loose notes into STAR stories
  • keeping track of follow-ups

But there is an important boundary.

AI may help with the shape. It must not remove ownership.

If I cannot defend a sentence in an interview, it should not be in my CV.

If I do not want to explain a technology during an interview, it should not be highlighted as a core skill.

If AI makes the text sound like someone who has been “passionate about scalable solutions” since kindergarten, the text needs to come back down to earth.

That may be the most important rule:

Use AI to become clearer.

Not smoother.

The Blog Became Part Of The Proof

One of the most useful moves was connecting the job search with my blog.

Not as a grand personal brand project.

More as practical documentation:

  • Here is how I think about DevOps.
  • Here is how I think about AI in production.
  • Here is how I think about observability, governance and platform work.
  • Here are concrete examples that I can write clearly about technical systems.

That gives a different kind of proof than a CV.

A CV says:

I have worked with this.

A good technical blog says:

This is how I think when I work with this.

Both are useful.

But in senior roles, the second one often matters just as much.

The Most Useful Result Was Calm

The biggest effect of the system was not that everything became perfect.

It did not.

There was still waiting. Still uncertainty. Still roles that fit better on paper than in reality. Still days where it felt a little like sending small bottles into an ATS system with poor lighting.

But the system made the work calmer.

When something stalled, I could ask:

  • What is the next concrete action?
  • Which role matters most right now?
  • Is this CV work, outreach, interview prep or follow-up?
  • Do I have a good story ready?
  • Should I adjust the strategy, or simply continue?

That is much better than:

What is wrong with me?

Sometimes the answer is not deep existential analysis.

Sometimes you just need a tracker.

My Small Checklist

If I had to give my job-search system to another developer, it would be this:

  1. Make a prioritized list of roles.
  2. Split them into tracks so you do not change identity for every application.
  3. Write one clear positioning sentence.
  4. Make a small playbook for each strong role.
  5. Save each CV version you send.
  6. Prepare 4-5 short interview stories.
  7. Follow up after a few business days if the process is silent.
  8. Use AI for structure, not polish.
  9. Use portfolio, blog or projects as proof.
  10. Review weekly, not after every individual rejection.

Job search will never become completely rational.

It is about people, timing, needs, chemistry, budgets and many things you cannot see from the outside.

But you can make your own part more operable.

For me, that has been the most useful way to think about it:

Job search is not only a series of applications.

It is a small system.

And small systems get better when you give them structure, feedback and a little observability.

Read Also

Note

This post is based on my own job-search notes, CV iterations, interview preparation and workflow experiments from 2026. I have left out concrete company details, live hiring processes and private contact information.