NOTE · 005
Looking for a Developer Job in 2026 Is a Job in Itself
Learning to code seemed like the difficult part. Then I discovered that finding an opportunity also requires building, explaining, applying, and preserving enough energy to keep learning.
I thought learning to code would be the hard part
When I started taking web development seriously, the difficulty looked fairly straightforward. I had to understand HTML and CSS beyond copying examples, learn JavaScript, get used to errors, discover why something worked on one screen and broke on another, and accept that every answer opened three new questions. It was a lot, but the work had a direct relationship with the result: I studied, practiced, and could see an interface becoming better than the one before it.
For a while, I assumed that if I learned to build real things and solve problems without depending on a recipe, there would eventually be a moment to show that work and talk to someone. I did not expect the process to be automatic. I did expect the central challenge to remain proving that I could do the job.
Looking for an opportunity in 2026 has forced me to adjust that idea. Programming is still essential, but it no longer feels like the whole test. Before a conversation can happen, I also need to show that I can present what I know, explain how I think, navigate very different requirements, and turn months of learning into signals someone can review quickly.
Opening a real job post changes the scale
A job description can begin with a technology I know and, a few lines later, accumulate frameworks, cloud platforms, testing, databases, automation, system design, methodologies, English, and production experience. Some lists describe an entire team better than one person. Others are reasonable, but give essential requirements, useful additions, and tools that may appear once a year the same visual weight.
I do not think every company writes job posts in the same way, or that every listed requirement is a rigid barrier. I also understand that a description is trying to cover real needs and reduce uncertainty. Still, my experience reading them is that separating “I can contribute here” from “I still need to learn this” becomes a skill of its own. Applying requires judgment, not just matching keywords.
The word “junior” does not always remove that ambiguity. Sometimes it sits beside expectations of substantial experience with real products, technical decisions, and independent ownership. That does not make the opening illegitimate, but it makes it difficult to know when potential matters and when previous experience is effectively the main filter.
A project does not speak for itself
Projects help, but a screenshot and a technology list say very little about the work behind them. What problem was I trying to solve? Which decision was mine? Which constraint changed the design? What failed? How did I validate it? What would I do differently now? If I cannot answer those questions, a project may look finished without proving much.
I think that is a healthy expectation. Writing code is only one part of development. Architecture, accessibility, performance, progressive enhancement, and maintenance matter precisely when something stops being an isolated exercise. The problem begins when preparing the explanation takes so much time that the project starts existing for the presentation rather than for the learning.
This portfolio became one response to that tension. I did not want a gallery that simply said, “I know these tools.” I wanted evidence of decisions: why a route keeps its content without JavaScript, how an animation returns stable state to CSS, and why a confidential project does not need a fake interface to look real. Explanation is work too, but I want it to grow from what I built rather than from a story added afterward.
The search has its own backlog
The résumé needs a clear version. LinkedIn asks for another way to tell the same story. Each platform requests information that is already in the CV. Some applications need a cover letter; others ask specific questions; others require an account before the form can even be completed. Then there is my own tracking: which opening it was, when I applied, which version I sent, and what I need to prepare if there is a next step.
None of those tasks is absurd on its own. Together they become a real workload. I have to read carefully, adapt without inventing, check links, avoid mistakes, and decide how much time each opportunity deserves. On a bad day, the search creates a lot of activity and very little feeling of progress, because the outcome depends on decisions happening outside my screen.
Technical exercises and interview preparation add another layer. It makes sense to review fundamentals, practice explaining decisions, and be ready to solve something under time pressure. It also makes sense not to turn every possible interview into weeks of preparation before anyone has replied. I am still learning where that boundary belongs.
Proving ability before the conversation
The strangest feeling is that a significant part of the evaluation happens before anyone decides to speak with me. The résumé must survive a quick scan. The profile has to be coherent. Projects need to load, explain their scope, and show judgment. The application has to answer the opening without sounding manufactured. All of it tries to answer a question nobody has asked me directly yet: can this person contribute here?
I do not mean that as an accusation. Reviewing candidates takes time, and companies need filters. From my side, the effect is clear: every piece of evidence has to work without extra context. That favors results that are easy to scan, while real development is usually full of nuance. A correct decision may look less impressive than a demo; a well-managed constraint may be invisible; a maintainable solution may need more explanation than a library list.
Learning to communicate those things is part of the craft. I only try not to confuse communication with spectacle. I do not want to promise confidence I am still building or disguise laboratory work as client experience.
AI accelerates production, not responsibility
AI is already part of my workflow. It can help me research an API, compare approaches, produce a first prototype, identify a debugging hypothesis, or review whether I missed a case. It can explain a concept differently when the documentation has not clicked yet. Used well, it reduces friction and makes wider exploration practical.
But faster production changes the question. If I can generate a function, an interface, or an explanation in minutes, it matters even more that I know whether it belongs in the system. I have to recognize wrong assumptions, find defects, review accessibility, test failure states, and understand the code I accept. When the result breaks something, I cannot delegate responsibility to the tool.
That also affects how I present my work. It makes no sense to pretend I develop without assistance, but saying I know how to use AI is not evidence by itself. What matters is which decisions I keep, what I reject, how I verify the result, and whether I can explain it without hiding behind the prompt. Speed is useful. Judgment and ownership of the final result are still mine.
The danger of becoming a candidate instead of becoming a developer
This is the conflict that concerns me most. It is easy to fill a week with tasks that look productive: adjust the résumé, rewrite the LinkedIn headline, search openings, complete forms, adapt cover letters, rehearse answers, and prepare for tests. Every task has a reason. At the end of the week, however, I can discover that I built nothing, debugged nothing difficult, and learned no idea I could apply.
Then an uncomfortable loop appears. To become a better candidate, I need better projects and better judgment. To present those projects, I need to spend time being a candidate. The more uncertain the search feels, the easier it is to optimize the presentation. The more I optimize the presentation, the less time remains for the activity I originally wanted to present: development.
I have not solved that tension with a formula. I try to protect blocks of time for building, even when applying feels more urgent. Sometimes that means improving an existing interaction instead of starting another project. Sometimes it means documenting a decision, fixing a lifecycle failure, or removing dead code with evidence. Those advances are less visible than submitting an application, but they keep the craft alive.
Building real things while I search
A “real project” does not have to be a huge platform or a famous brand. For me, it means there are constraints, possible users, content I cannot invent, and consequences when I make a poor decision. It can be professional work whose details need to stay confidential, a small utility, an experiment that admits its limits, or this portfolio operating as a public system.
Continuing to build gives me something the search cannot always provide: direct feedback. If a link is broken, I can find it. If the design overflows on mobile, I can measure it. If an animation leaves inline state after cancellation, I can define who should own the final state. The problem does not disappear because I describe it well; I still have to solve it.
It also keeps every project from becoming a performance for recruiting. I want what I show to work as evidence, but first it should help me learn and improve. An interface built only to look complex teaches me less than a simple system whose failures I had to understand.
Explaining without inflating
Job searching creates pressure to use large words: impact, architecture, leadership, scalability. Some belong to the work; others can make a small experience sound like something it was not. I want to describe scope without diminishing it, but also without turning every decision into a business transformation.
I can say that I built a bilingual multipage portfolio, defined progressive-enhancement contracts, and tested routes with browser automation. I do not need to claim that I designed a global platform. I can mention reserved professional work without exposing private details. I can show technical laboratories as laboratories, not as clients.
Honesty may not produce the most impressive sentence, but it makes a real technical conversation possible. If someone asks about a decision, I want to be able to walk through the code, explain the context, and acknowledge where my experience ends.
The portfolio became work too
There is an obvious irony here: I built the portfolio to look for work, and then the portfolio became another job. It needs content, architecture, accessibility, visual review, metadata, equivalent routes, testing, and maintenance. It can consume time indefinitely if I use it to avoid the discomfort of applying.
That is why I try to give it boundaries. Not every improvement deserves another iteration. Stable code does not need a refactor simply because it is long. An approved route should not be redesigned out of boredom. The value is in keeping the system understandable and ensuring that the evidence represents how I work now, not in keeping it in permanent motion.
These Engineering Notes serve a similar purpose. They are not exhaustive documentation or a content strategy. They are pauses to record what I learned, which tension appeared, and why I made a decision. If writing a note forces me to understand my work better, it improves the evidence too.
What I can control
I do not know which application will turn into a conversation or which conversation will become an opportunity. I also do not know whether the right person will arrive through a vacancy, a shared project, a recommendation, or a path I am not looking at yet. Pretending certainty would not make the search shorter.
What I can control is continuing to develop judgment, building things that survive technical review, and presenting the experience I actually have. I can protect time so that applying does not replace learning. I can use AI to move faster without handing over the final decision. I can acknowledge that looking for work is work while refusing to let it occupy all the space.
This portfolio, the projects, and these notes are part of that process. They do not guarantee an opportunity. They leave a verifiable trail of how I think, what I build, and what I do when something does not work. While I still do not know which application will be the right one, that is the kind of evidence I can keep making better.