Job searching while unemployed isn't just challenging—it's emotionally draining. Before diving into tactics, understand this: protecting your mental health is non-negotiable. You'll get your hopes up repeatedly, only to face rejection. Getting hired on your first few processes is extremely rare, so brace yourself for the long haul. Accept that rejection is part of the process, not a reflection of your worth. Establish a routine that includes breaks and self-care, and connect with other job seekers for mutual support.

Project Confidence (Even When You Don't Feel It)

Even though you might go through dozens of processes and face rejection after rejection, you need to keep your morale up and be confident (not arrogant) when talking to interviewers. Someone who truly knows their stuff should appear confident—don't talk like you need validation. Companies looking for senior candidates want decision-makers who know when to choose one solution over another. If you can't feel confident yet, keep learning and practicing until you get there.

Timing Matters More Than You Think

Not all months are created equal in the hiring world. Peak hiring typically happens from January through April (new budgets, fresh headcount) and September through October (final push before year-end). May, June, and November see moderate activity—roles exist but with slower momentum. The slowest periods are July, August, and December with fewer postings and delayed processes. Keep in mind that startups and hyper-growth companies often buck these trends and hire continuously, but understanding these patterns can help set realistic expectations.

Treat Job Searching as Your Full-Time Job

When you're unemployed, your new role is getting noticed. Apply to jobs daily across multiple platforms. Create content through blog posts, YouTube videos, or LinkedIn updates. Network actively and make new connections. Ensure your resume and LinkedIn profile are aligned and to-the-point. Be bold and contact recruiters directly after applying—you'll stand out from the 90% who don't take this extra step. Some recruiters might not love this advice, but being proactive can make all the difference.

Never Stop Applying (Even When Things Look Promising)

Here's a critical mistake many people make: you'll have interviews where you feel like you absolutely nailed it. The conversation flows, the technical round goes well, and you start thinking "this is it, I'm about to get an offer." That's when the temptation hits to slow down on applications. Don't do it. Keep applying with the same intensity until you have a signed offer in hand. If you stop because you think you're about to land a job, you risk losing weeks of valuable time when that "sure thing" falls through. I've seen people coast for two weeks only to get rejected and have to rebuild momentum from scratch. The pipeline needs to stay full.

Master Your Stack (Don't Spread Thin)

If you specialize in one stack, stick to it and go deeper. Solidify fundamental concepts in your core technologies. Study the tools you claim expertise in until you truly own them. A solid base makes a solid candidate. Only apply for roles that match your actual stack—spreading yourself thin will hurt more than help.

Make sure to match keywords to job descriptions. If a role wants "Node, React, Lead, Manage," those exact terms should appear in your resume. However, don't fake expertise just to get called for an interview. You'll be exposed during technical rounds anyway, and you'll have wasted everyone's time including your own.

Navigate the AI-Changed Landscape

The IT market is drastically different than previous years. AI is everywhere, and many candidates now use it to generate tailored resumes, complete take-home assignments, or even cheat in live coding interviews. Here's the reality: companies with solid processes and good interviewers will filter out AI-dependent candidates. Use AI to improve yourself and your materials, but never rely on it during actual interviews. Most jobs today can be done with AI assistance, but to pass interviews you need to show you deeply know what you're doing. Your genuine knowledge and experience will be your differentiator.

Practice the Technical Fundamentals

Yes, you need to study LeetCode even if it feels artificial and rarely mirrors daily work. It's the industry standard for companies to assess how deep your knowledge goes. Study data structures and know when to use each one for different solutions. Get at least a basic understanding of how Big-O notation works and how to identify it. Keep coding manually—don't just read about concepts, actually implement them.

Build Projects That Prove Your Experience

Code side projects that showcase skills you want to use professionally. Manually set up and build fun projects that try out concepts you haven't worked with yet—a real-time chat app, something that integrates with the OpenAI API, or an impressive personal website. Pay attention to what technologies most similar roles are asking for and get good at them. You'll definitely stand out if you have a live project similar to what your target company does. For example, if you're applying to SaaS companies, they'll want you to have at least one live SaaS project to show and prove your experience.

Learn from Others' Experience

Watch mock interviews on YouTube like you're watching a teacher and take notes. They're incredibly helpful for understanding what's expected at each step of the process. Most software companies have at least one live coding step and another system design step. Watch experienced engineers design complex systems in mocked interviews and try to understand their way of thinking and problem-solving process. Sometimes you can even find real interview recordings, which gives you the best preparation possible. Keep studying.

Document Everything and Iterate

Keep attending interviews, get feedback, and document each hiring process. Note which steps you passed and failed, list every weak point you had in each interview, and work on those areas to flatten your knowledge gaps. The more interviews you take, the better you'll get for the next one. This applies to both technical and soft skills. Each rejection is just practice for the acceptance that's coming.

Final Thoughts

This journey isn't easy, and there are no guarantees. The market is tough, the process is grueling, and even doing everything right doesn't guarantee success. But these strategies can improve your odds and help you grow as an engineer regardless of the outcome. Stay hungry, stay learning, and keep pushing forward.

TL;DR: Key Takeaways

Protect your mental health first — rejection is normal, not personal. Understand hiring seasonality to set realistic expectations (peaks: Jan-Apr, Sep-Oct).

Project genuine confidence — speak with conviction about what you know, make clear technical decisions, avoid seeking validation.

Make job searching your full-time job — apply daily, create content, network actively, and contact recruiters directly after applying.

Never stop applying — even when an interview goes great and you feel confident, keep the pipeline full until you have a signed offer.

Go deep, not wide — master your stack completely, match resume keywords to job descriptions, but never fake expertise you don't have.

Use AI wisely — leverage it to improve your materials and skills, but never depend on it during actual interviews.

Practice the fundamentals — LeetCode, data structures, Big-O notation, and hands-on coding are non-negotiable.

Build relevant projects — create live projects similar to what your target companies do.

Learn from others — watch mock interviews and system design videos, take notes, understand thinking processes.

Document and iterate — log every interview, identify weak points, improve continuously. Each interview makes you better at the next.

Angular: The Opinionated Framework

Angular is used by 19.8% of professional developers according to the 2025 Stack Overflow survey stackoverflow, making it the fourth most popular web framework. When it comes to developer satisfaction, Angular has a 44.7% admiration rate (developers who used it and want to continue) and 11.4% desire rate (developers who haven't used it but want to) stackoverflow.

Angular stands apart as a complete framework, not just a UI library. It comes with a powerful CLI for project creation and component generation, plus built-in routing, SSR, and validation right out of the box.

What truly differentiates Angular is its philosophy. The documentation guides you toward specific design patterns—Angular is deliberately opinionated about how you should build. For your project, this means:

The advantages:

• Most Angular developers will get up to speed faster because projects follow similar structures

• You can build things differently, but Angular makes it easier to follow established conventions

• Experienced Angular developers should become productive quickly

• The framework shares structural similarities with NestJS (a backend framework used by 7.4% of professional developers with 62.2% admiration stackoverflow), making it easier for full-stack developers to transition between frontend and backend work

• Built-in testing philosophy and tools reduce decision fatigue

• TypeScript-first approach ensures type safety across your entire codebase

• Backed by Google, providing enterprise-level stability and long-term support

The challenges:

• Finding experienced Angular engineers is difficult

• The learning curve for developers new to Angular is steep

• Lower developer satisfaction compared to newer frameworks

React: The Flexible Library

React dominates as the most popular web framework, used by 46.9% of professional developers stackoverflow, far ahead of any competitor. React shows strong developer satisfaction with 52.1% admiration and 30.7% desire stackoverflow, meaning both current users want to continue and non-users want to try it.

React takes a fundamentally different approach as a UI library rather than a framework. Need routing, validation, SSR, SSG, or state management? You'll need to either build your own solution, adopt separate packages for each need, or use a framework like Next.js (used by 21.5% of professionals with 45.5% admiration and 14.9% desire, making it even more popular than Angular stackoverflow) or Vite on top of React.

This flexibility has consequences. Each React project likely uses different packages and configurations, meaning developers face a learning curve with every new codebase. React's documentation explains how to code within files but offers no guidance on folder structures, leaving each project to establish its own conventions.

The advantages:

• By far the most popular solution with abundant packages available

• Huge talent pool of 46.9% of professional developers actively using it stackoverflow

• Very similar to React Native, making it easier to transition web developers to mobile projects

• Backed by Meta, ensuring continued development and corporate adoption

• TypeScript support is excellent (TypeScript is used by 48.8% of professional developers with 58% admiration stackoverflow) but optional, giving teams flexibility

• Mature ecosystem with solutions for virtually any problem

• Strong developer satisfaction indicates developers enjoy working with it

The challenges:

• Code quality depends heavily on developer choices and experience

• Less standardization across projects means higher onboarding time

• Requires more architectural decisions upfront

• Testing libraries must be chosen separately (Jest, React Testing Library, etc.)

Vue and Svelte: The Accessible Alternatives

Both Vue and Svelte are frameworks that offer more structure than React while maintaining approachability.

Vue (used by 18.4% of professional developers with 50.9% admiration and 15.3% desire stackoverflow) provides official packages for routing and state management, giving you a more cohesive ecosystem without Angular's rigidity. This middle-ground approach means less decision fatigue than React while retaining flexibility. Vue is community-driven and independent, which has fostered a particularly welcoming ecosystem but may give some enterprises pause compared to corporate-backed alternatives. TypeScript support is strong and increasingly emphasized in Vue 3. The developer satisfaction metrics show Vue users are happy with their choice and there's healthy interest from non-users.

Svelte (used by 6.9% of professional developers with an impressive 61.3% admiration rate and 11% desire stackoverflow) comes with SvelteKit, which compares to Next.js in providing full-stack functionalities including routing, SSR, and more. Svelte's unique approach compiles your code at build time rather than using a virtual DOM, resulting in smaller bundle sizes and less runtime overhead—giving it a real performance edge in certain scenarios. TypeScript support is excellent and well-integrated. Despite its smaller user base, Svelte's high admiration rate indicates that developers who use it really love it.

The major caveat for both? Far fewer experienced candidates are available compared to React or Angular. However, both frameworks have notably gentler learning curves and can be learned more quickly than Angular or React.

So, Which Should You Choose?

Choose Angular if: You prioritize predictable project structure and want to minimize the learning curve for experienced developers joining your team. Following Angular's prescribed path is easier than creating your own conventions, and code quality tends to be higher because the framework nudges you toward best practices. It's also ideal if you value enterprise backing and built-in TypeScript. However, be aware that Angular has lower developer satisfaction compared to alternatives.

Choose React if: You need to build quickly and want easy access to new developers. With nearly half of all professional developers using React and strong satisfaction ratings, you'll find a solution for almost anything, but you'll need to make more decisions upfront. Just be aware that code quality will depend heavily on your team's choices and experience.

Choose Vue or Svelte if: Your team already has experience with either framework, or you want a gentler learning curve for developers new to modern frontend development. Both show strong developer satisfaction, with Svelte users being particularly enthusiastic about the framework. Be prepared for challenges when hiring developers with prior experience in these technologies.

One final consideration: If you already have an existing project in any of these frameworks, the cost of switching is rarely worth it. Migration between frameworks is expensive and time-consuming. Unless you have compelling technical or business reasons, stick with what you have and invest in improving your current codebase.

The bottom line? Your choice should align with your team's experience, hiring priorities, and how much structure versus flexibility you need for your project.

The problem

As a frontend developer, I have often seen designers make wonderful designs but when the pages from Figma are transformed into code, in a team with more than one developer, after a few component implementations, there is usually a style/code duplication.

That happens because the designers tend to go straight to designing big components. And so do the developers. If we start like this, the styling will be hardly consistent throughout the application, the code will be duplicated and a lot of productive development time will be wasted.

The solution

To fix this problem, there will need to be an effort both from the design team and the developer team.

1. Think of every section of the application as a combination of smaller components.

2. Begin by designing small components first, which can be reused in both design and code. Usually, these are Texts, Headings, Inputs, Buttons and other small items that you plan to reuse in bigger sections.

3. You and the team should enforce that the frontend development should start with the smallest components first, then medium, and then bigger components.

4. Keep reusing components and maintain a consistent style.

5. If you, the designer, notice that a new page/section that you are designing needs a different small component that you have never used before, you NEED to point this out to the assigned frontend developer so that your new small component is implemented before the bigger section that uses it. This will ensure that the next time this same component is used, it will maintain a consistent look and behavior.

The outcome

Of course, this way of working tends to slow down the start of a big project but if your project is a long-term one, this solution will ensure that once a component is designed and implemented, there should be almost no rework needed both for the designer and the developers once that same component can be reused throughout the application.

There will be a time when the team will notice that when coding a brand new page or section, most of the work from the developer will go into just importing previously done components and getting the right data to it. Almost like a drag-n-drop code solution.

I'm currently on a project that is already benefitting from this approach and there were multiple cases in which the development work for building a new page was as easy as importing components, instantiating them in the right order, getting the page data from a CMS API and passing the data to each component. No styling work needed.

This solution speeds up the development time exponentially and the following chart exemplifies approximately how the development speed should grow as the project ages. This curve should happen because each new page will probably contain components that were already previously developed.

A known solution

There is a methodology called Atomic Design which takes all that into account and simplifies it into an easier way to understand the concept. You have multiple levels of component complexity, starting with very simple components, usually with only one goal, and then those smaller components are used in bigger ones until we get to the final level, which should be what is displayed to the user as a result.

Here is an example:

• Atoms: input, label, button

• Molecule: a component that combines one input and one label

• Organism: a component that combines multiple molecules to create a form with multiple inputs, labels and one button

• Template: a component that takes the form organism and puts it into a section that is meant to be used on pages

• Page: a /contact page that uses the previously created section to display a nice cohesive form section

You can read more about the Atomic Design Methodology in this great article written by Brad Frost.

Final notes

As for my own experience, the solution explained above results in a great improvement in development speed, code quality, and reusability and I would recommend it for any long-term project.

If you like this article, subscribe to my newsletter and if you want to share your own experiences or thoughts on the topic, feel free to leave a comment.

You can also contact me through LinkedIn and if you want to know a little bit more about me, check out my website at hildor.dev.

Growing up with a computer and enough free time to spend on it after school sure gave me a lot of experience in the world wide web. Most of my interest went into PC gaming and video recording stuff. So I spent most of my time playing video games, watching Youtube and trying to figure out how to do some of the cool stuff I always saw on the web.

As curious as I am, I learned how to record my screen and edit the videos to post them on Youtube. First went into recording general PC tutorials, for example, on how to record CDs and DVDs to play on other platforms, such as an unlocked PS2 at the time. I also created a blog where I posted links to programs to be downloaded and my tutorials were also published there. The blog was called MoskaDowns. It did give me a lot of knowledge on Photoshop and HTML as I would search for how to do anything on Youtube.

After publishing some video tutorials I went into recording gameplays and after about 40 videos I got to the great mark of 400 subscribers. A lot at the time but as I grew, I felt embarrassed about my old videos and decided to delete every single one of them (one of my biggest regrets). The Youtube career never really took off but for sure was one of my greatest hobbies and I'll probably get back into it someday.

At that time I also loved to watch WWE (Rey Mysterio FTW) and I watched the shows on a website that had it streamed and also had an online radio. Of course, I couldn't just watch the show as everybody else, I needed to be involved. So after contacting the owner of the website, I got to be the online DJ of that website radio from time to time. That also was a great experience as people in the stream chat asked for songs and commented on the playlist I chose at the time.

The gaming YouTuber phase was awesome and I even got to create a Minecraft server from scratch with my friends with the intention of hosting it for my subscribers and my friends to play in. It was a great time as I had some of my first experiences with code and development. Setting up the game server and its plugins took me some time but I was learning a lot on the way. For the server I also did my first website, using only HTML and CSS (and iframes to create the layout) at that time. The server did pretty well, I published some videos to my channel with hopes to get some of my subscribers into it and it worked. I remember there were about 15 daily players in it. I loved watching them enjoy a creation that my friends and I had spent so much time making. As a kid, I didn't have much money to invest into the server hosting so I needed to have enough paying VIPs on the server to cover the costs but it never got more than 1 or 2 paying players. So unfortunately after about 3 months of the server running, I had to turn it off. That time must have been in the 2010s. As time went on I lost the server files but for sure would love to revive that Minecraft map and see it again.

As you can see, my childhood was heavily based on the online and virtual worlds. So when I finished High School, going to Computer Science in College was pretty much written in the stars. I remember being in doubt about choosing Psychology or Physical Education as well but the most logical choice was the one that I took, Computer Science-related course.

After joining PUCRS, the biggest private university in the south of Brazil, in 2016, I entered the world of web development in my first internship and kept on learning in school and in the jobs I had. Kept growing as a developer and kept going for different roles and technologies at a range of companies that seemed like the right fit for me. Ended up choosing to focus on the front-end part of the development as it was always the most satisfying work for me.

All the online experiences I had in my childhood sure seemed like nothing useful but today I know that all those different fun times I was having as a kid were, in fact, little by little, giving me a bit of the knowledge I use today on my day to day work life.

Of course, there are not only positive points to a kid having a lot of online time but I hope this article can serve as a good example for you to know how some kid that is always playing video games or watching videos on the internet sometimes may be, unknowingly gathering a bunch of useful information that later in life can facilitate the work that will be done by him or her.