Treating My Job Search Like an Engineering Project

Job hunting is not what it was five years ago

A few years ago, you could write one solid résumé and send it to almost any company. You might adjust a few lines or rearrange your skills, but one general-purpose CV was usually enough.

That approach has largely stopped working. The rules changed: with large language models, tailoring a résumé to a specific job now takes minutes. Once everyone has access to the same tool, the tool itself stops being an advantage. Recruiters receive hundreds of polished documents optimized for the same role, so the real competitive advantage is no longer the CV. It is the process around it.

That was when I realized I did not need another résumé generator or a collection of prompts. I needed an engineering system that could take me from the first interesting vacancy to the technical interview.

If a process repeats, it can be designed

As an engineer, I tend to look at repetitive work in the same way: break the process into stages, standardize the stages, and automate the mechanical parts. I stopped thinking about job hunting as a collection of unrelated documents and started treating it as a pipeline:

Each stage had a clear input and output, and each could be improved independently. At that point, job hunting stopped feeling chaotic.

The first question was not about the résumé

The most surprising discovery was that writing a CV should not be the first step at all. The first question is much simpler: do I actually want to work at this company?

I used to open an interesting vacancy and immediately start adapting my résumé. Now I did the opposite. I researched the company first: what product it was building, what problem it was solving, what stage it was at, which engineering challenges the team faced, how decisions were made, and whether any of this matched what I wanted to spend the next few years doing.

This stage unexpectedly saved the most time. A role could look perfect on paper: a modern stack, a good salary, a recognizable name. Yet deeper research sometimes showed that I did not care about the product, the engineering problems did not match my goals, or the company culture simply felt wrong. Sometimes the best application decision was not to apply.

The job description stopped being prose

Once I decided that a company was worth pursuing, I worked with the job description, but I stopped reading it as ordinary prose. I converted it into structure: mandatory and optional skills, repeated technologies, hidden expectations, scope of responsibility, signals of a leadership role, and the real problems the company expected the new engineer to solve.

After reviewing dozens of vacancies, it became clear that most of them are built from similar components. What changes is not the components themselves, but their priority.

Instead of generating a new résumé, I searched for differences

The next stage compared two datasets: the company's requirements and my experience. The goal was not to create a beautiful new CV. It was to find the difference between them.

Where did I genuinely lack experience? Where was the company using different terminology? Where had I already solved a similar problem but described it in language that made sense inside my current team rather than to an external recruiter or ATS?

It was important not to embellish reality. The goal was the opposite: to present existing experience honestly in the language of a particular company. This kind of gap analysis proved far more useful than asking AI to write the perfect résumé from scratch.

ATS was not the enemy

I also wanted to understand how Applicant Tracking Systems read my CV. Not to game the system or stuff the document with keywords, but to check whether it could see the experience I actually had.

Sometimes the problem was not missing experience but wording. Something obvious to an engineer inside my team could be invisible to an automated system or recruiter. Small changes made the experience easier to recognize without adding a single untrue claim.

The résumé became a build artifact

The most successful technical decision was also one of the simplest: I stopped editing PDFs by hand. Projects, technologies, achievements, and responsibilities lived separately as structured data, while the document itself became a build output.

A single LaTeX template provided stable layout and formatting. For each vacancy, the pipeline selected the relevant facts and wording, then produced a new PDF. CV generation started to feel like building software: change the input, run the process, and receive a reproducible artifact.

The most valuable part turned out to be something else

I expected résumé generation to be the main advantage of the system, but I was wrong. Interview preparation created the greatest value.

Based on the vacancy, the system generated questions about technologies, architecture, leadership, my own projects, and potential weak areas. It quickly became clear that the real value was not the list of questions. It was the need to formulate the answers in advance.

Rebuilding my engineering vocabulary

When you work at the same company for years, knowledge gradually becomes intuitive. You keep solving difficult problems, but you stop naming the approaches you use. You can explain a migration in detail yet fail to recall the term Strangler Fig Pattern immediately. You can describe an architecture without saying CQRS, or explain the behavior of a distributed system without using the phrase eventual consistency.

Interview preparation forced me to reconnect real experience with shared engineering terminology. I revisited pattern names, articulated trade-offs, and learned to explain in one or two sentences decisions that previously took several minutes to describe. This was not about memorizing buzzwords. The right term simply created shared context with the interviewer faster.

Good stories require preparation too

Almost every interview includes similar prompts: tell me about a difficult project, a conflict, a technical decision, or an architectural compromise. I used to reconstruct the answer during the conversation, sometimes forgetting important details, spending too long on context, or choosing a weaker example.

The framework made me analyze my own stories in advance: what the problem was, why it was difficult, which options we considered, why we chose a particular solution, and what happened afterward. This did not turn the answers into scripts. It gave me a better mental model of my own experience, so I could adapt the story naturally to the interviewer's question.

When preparation met reality

The most satisfying surprise was how often the questions from my preparation appeared in real screening calls and technical interviews. They were rarely identical, but often close enough to feel like a second attempt.

That changed more than the quality of my answers. It changed my state of mind. I no longer had to search for the right phrasing or invent an example under pressure. I was explaining ideas that I had already considered calmly and rehearsed several times.

AI was not the main character after all

Looking back, AI was only a tool. It helped analyze vacancies, structure requirements, draft wording, and generate questions, but every important decision remained mine.

Should I apply? Is this company right for me? Does the CV describe my experience honestly? Which story best answers the question? The framework did not make those decisions on my behalf. It removed repetitive mechanical work so I could focus on decisions that genuinely required human experience and responsibility.

Final thoughts

When I started this project, I thought the goal was to tailor résumés faster. Over time, I realized that the real advantage was something entirely different.

The process helped me restructure years of professional experience, revisit architectural decisions, recover precise engineering vocabulary, and prepare real stories instead of improvising. Job hunting became a clear and repeatable engineering process rather than a chaotic collection of tasks.

The most useful project I built during my job search was not another service or home automation. It was a pipeline that helped me understand and communicate the story of my own career far better.