<![CDATA[ Ilyas Seisov - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ https://cdn.freecodecamp.org/universal/favicons/favicon.png <![CDATA[ Ilyas Seisov - freeCodeCamp.org ]]> https://www.freecodecamp.org/news/ Eleventy Thu, 14 May 2026 22:43:17 +0000 60 <![CDATA[ How to Prep for Technical Interviews – A Guide for Web Developers ]]> https://www.freecodecamp.org/news/how-to-prep-for-technical-interviews-guide-for-web-devs/ 69dd2c59217f5dfcbd261b21 Mon, 13 Apr 2026 17:48:09 +0000 Over the years I've participated in dozens of technical interviews.

I've answered technical questions one-on-one with the CTO and in a group with the dev team. I've taken quizzes with a timer and built features into existing apps in live mode.

I've live coded algorithms, done take home assignments, and demonstrated my system design skills.

And all this has given me a lot of knowledge and experience that I want to share with you now.

In this guide, I'll share my top tips, recommendations, and checklists to help you prepare for and pass your technical interviews. These will level up your game and increase your chances of getting a job.

What We'll Cover:

Introduction

The technical interview is designed to test how you think, code, and communicate. It's about both explaining your reasoning and showing what you can do. Think of it like a performance: the more you practice, the more natural and confident you’ll feel when you're actually doing it.

You’ll usually go through three main steps:

  • Technical screening: a short 15–30 minute call to check your basics and interest in the role.

  • Coding challenge: you’ll solve problems either through a take-home project or a live coding test. This shows how you write, structure, and test your code.

  • Whiteboard interview: you solve problems on a shared screen while explaining your thinking out loud. It’s less about being perfect and more about how you approach problems.

During these stages, interviewers focus on a few key areas:

  • Data structures: Ways to organize data (like folders in a filing system).

  • Algorithms: Step-by-step methods to solve problems.

  • System design (for senior roles): Planning how large systems work, similar to designing a building that supports many users at once.

Overall, they’re looking at how you think, not just what you know.

The Secret That Will Increase Your Interview Performance By 53% (at Least It Did For Me)

The secret is: narrow your focus.

Before you spend even one minute preparing, specify exactly what type of company you want to work for.

Why?

Because this choice will reveal what exactly you'll have study and practice before your technical interview.

Let's go over the main categories of companies so you can work on narrowing your focus.

1. Big Tech / FAANG-level Companies

(Google, Amazon, Meta, Apple, Microsoft)

Core skills:

  • Data structures & algorithms

  • System design (scalability, distributed systems)

  • Computer science fundamentals (OS, networking)

2. Mid-size Product Companies / SaaS

(Shopify, Stripe, Notion)

Core skills:

  • Strong stack knowledge (React, Next.js, Node.js)

  • API design & integrations

  • Database design (SQL/NoSQL)

3. Startups (Early-stage)

Core skills:

  • Full-stack development

  • Rapid prototyping

  • Shipping features end-to-end

4. Design Agencies / Creative Studios

Core skills:

  • Advanced HTML, CSS, JavaScript

  • Animation (GSAP, Framer Motion)

  • Pixel-perfect implementation

5. Enterprise / Corporate Companies

Core skills:

  • Backend development (Java, .NET, and so on)

  • Databases (SQL, enterprise systems)

  • APIs & microservices

6. E-commerce & Marketing Agencies

Core skills:

  • Shopify / WordPress

  • Frontend development

  • SEO & performance optimization

7. AI-first / Modern Tech Companies

(OpenAI, Anthropic)

Core skills:

  • AI API integration (LLMs, embeddings)

  • Prompt engineering

  • Backend & data handling

8. Freelance / Indie / Micro-SaaS

Core skills:

  • Full-stack development (Next.js)

  • Payments & authentication systems

  • Deployment & basic marketing

Keep in mind that these are just high-level recommendations. There are, of course, other skills you'll need to focus on depending on the role you're hoping to get. This is just a general guideline to get you started.

Also, fun fact: if you ask a top FAANG developer to code an Awwwards-style landing page, they'll most likely fail. And similarly, an award-winning web designer from a top notch agency will probably perform poorly at an algorithm assignment. Why? Each field requires its own skillset. So make sure you choose and focus on yours.

Step 1: Building a Strong Foundation in Core Web Development Concepts

So, now I assume that you've decided on the type of company you want to work for.

The next step is check whether you have or need to work on the basic fundamentals. Most candidates fail not because they lack experience, but because their basics are shaky.

A solid foundation makes everything else easier: coding challenges, system design, and even real-world tasks.

Focus on learning the core building blocks:

  • HTML & CSS

  • JavaScript fundamentals

  • One solid framework: Get really good at one stack (like React + Next.js).

  • APIs & backend basics: Learn how data flows. Understand REST APIs, authentication, and how frontend connects to backend.

  • Databases: Know the difference between SQL and NoSQL. Be comfortable with basic queries and data modeling.

  • Git & workflows: You should be confident with version control, branching, and collaborating on code.

The goal is not to know everything. The goal is to be clear, confident, and consistent in the fundamentals.

If your basics are strong, you’ll solve problems faster, explain your thinking better, and stand out naturally in interviews.

One of the most effective ways to get better at fundamentals is by practicing with flashcards. I've created a system called the 99cards app that can help with this if you want to check it out.

Step 2: Going Deeper Into Subject Matter

By this step, you've chosen the type of company you want to work for and you're confident that you know core web development skills.

Next, you'll need to practice specific skills related to your company and preferred job type (for example algorithms or building features in live mode).

Hint: In about 80% of cases, the first step is an HR interview. This happens before the technical round. Use this opportunity to your advantage.

When I get invited to a technical interview, the first thing I do is ask the HR manager what I should prepare. Just a simple question – and surprisingly, I almost always get a clear answer concerning:

  • What topics to focus on

  • What kind of tasks to expect

  • Sometimes even tools or formats they’ll use

This gives you a huge advantage. Instead of guessing, you can prepare with intention.

Interview Preparation Guide

1. Answer Technical Questions (1-on-1 / Many-to-1)

This is usually a conversation with a CTO or a full dev team. They'll want to understand how you think, not just what you know. Stay calm and treat it like a discussion, not an exam.

Keep your answers simple and structured:

  • Explain your thought process step by step

  • Use real examples from your experience

  • If you don’t know something, say it and think out loud

In many-to-one interviews, don’t get overwhelmed. Focus on one question at a time and engage with the person speaking.

For example, when I was looking to hire a web developer for my micro SaaS, I didn't care about algorithms, but I cared deeply that they have thorough Next JS skills.

For that, I tested candidates via flashcards in live mode.

How to effectively prepare

Practice explaining concepts out loud, not just in your head. Pretend you’re teaching someone.

Do mock interviews with a friend or record yourself. Focus on clarity and structure.

  • Prepare stories from past projects

  • Review core concepts (JS, React, APIs)

  • Practice saying “I don’t know” confidently

2. Go Through Quizzes with a Timer

Timed quizzes test your speed and basics. These are often multiple-choice or short coding questions. The goal is accuracy under pressure.

A few tips:

  • Don’t spend too long on one question. Skip and come back if needed.

  • Practice common patterns beforehand.

Speed improves with repetition. Train like it’s a game.

How to effectively prepare

Use platforms with timed tests to simulate pressure. Track your speed and accuracy.

Focus on common topics that appear often.

  • JavaScript fundamentals

  • Basic algorithms

  • Output-based questions

Practice daily in short sessions. Consistency beats long study sessions.

3. Build Features into Existing Apps (Live Mode)

During technical interviews, you’ll often work on a real or mock project. This tests how you read code, understand structure, and make changes safely.

Focus on:

  • Understanding the codebase first

  • Asking clarifying questions

  • Writing clean, simple solutions

Talk while you work. Explain what you’re doing and why.

How to effectively prepare

Practice working with someone else's codebase (not your own). Clone open-source projects and explore them, for example.

Train your ability to navigate and understand code quickly.

  • Read files before coding

  • Trace data flow

  • Make small, safe changes

Also practice explaining your actions while coding.

4. Live Code Algorithms

This is where many developers struggle. You’ll solve problems in real time while explaining your thinking.

Don’t rush to code. First:

  • Clarify the problem

  • Talk through your approach

  • Start with a simple solution, then improve it

Interviewers care more about your thinking than a perfect answer.

How to effectively prepare

Practice common algorithm problems regularly. Focus on patterns, not memorization.

Solve problems out loud, as if someone is listening.

  • Arrays, strings, hash maps

  • Sorting and searching

  • Basic recursion

Time yourself and review your solutions after.

5. Take Home Assignments

These simulate real work. You get time to build something properly. This is your chance to stand out.

What matters most:

  • Clean, readable code

  • Good structure and naming

  • Clear README with your decisions

Don’t overbuild. Focus on quality, not quantity. A smaller, more focused take-home project that's done is better than an overly complex or overly ambitious one that's incomplete.

How to effectively prepare

Build small projects with real-world structure. Practice finishing, not just starting.

Pay attention to presentation and clarity.

  • Write clean commits

  • Add a clear README

  • Handle edge cases

Think like you’re submitting work to a real client.

6. System Design

This is common for mid to senior roles. You’ll design a system from scratch or improve an existing one.

Start simple, then expand:

  • Define the requirements

  • Sketch a basic architecture

  • Discuss scaling, performance, and trade-offs

Think like a builder, not just a programmer. Show how you make decisions.

How to effectively prepare

Study common system design patterns and real-world architectures. Start with simple systems.

Practice breaking problems into parts.

  • APIs and data flow

  • Databases and caching

  • Scaling basics

Watch system design interviews and practice explaining your ideas clearly.

For each of these interviews you can use my free checklists to prepare even more effectively.

A Fun Story

Once I applied to a front-end web developer job at company that focuses on building Awwwards-style websites. The tech interview was take home assignment: I had to rebuild Figma design into a modern GSAP-animated website. I failed to do that.

In 18 months, the same company had an open position. I applied. Can you guess what the tech assignment was? 😄

It was the same.

Draw your own conclusions.

Most Important Part

Here's a helpful framework to keep in mind when you're going through this process:

PDCA Framework

P - plan
D - do
C - check
A- act

It's my go to framework for every subject I want to get better at. Let me explain how to apply this to tech interviews.

Plan: in this stage, you plan your preparation routine and work on your interview performance game.

Do: in this stage, you're actually trying to do what you have planned.

Check: here, you compare your Plan and Do stages. Analyze the difference and see what you can improve.

Act: finally, make adjustments that will help improve Plan 2.0.

Repeat until you get the desired result.

Conclusion

Technical interviews are not about being perfect. They’re about showing how you think, communicate, and solve problems under pressure. The more you practice the right way, the more confident and natural you’ll feel.

Focus on the basics, prepare for your target company, and train in real interview conditions. If you do that, you’ll already be ahead of most candidates.

P.S.

If you want to speed up your prep and stop guessing, I put together a complete toolkit for you.

It contains:

  • Interview Checklists

  • CV Template

  • Cover Letter Template

  • List of Top 50 Remote-First Companies

  • Job Application Tracker Spreadsheet

You can find it here: 99cards.dev/toolkit

]]> <![CDATA[ The Ultimate Web Developer Job Search Handbook ]]> https://www.freecodecamp.org/news/the-ultimate-web-developer-job-search-handbook/ 699f5dc4c9015c37f6bc8f92 Wed, 25 Feb 2026 20:38:28 +0000 Getting a web developer job today is hard.

In 2021, I got my first developer job by sending one direct email and then doing a single live call. That was enough.

Later the same year, I found my second job in about three weeks through LinkedIn. At that point, I mostly knew CSS. No serious JavaScript, no strong portfolio, no polished personal brand. And I was offered a Senior Front End Web Developer position at US-based company.

Then things changed. After COVID, a lot of developers moved to remote work. Local job markets turned global almost overnight. Instead of competing with a handful of people nearby, you were suddenly up against hundreds of developers from everywhere.

By 2023, I had real experience. I’d worked at two companies – one in Europe and one in the US. I knew JavaScript, had a proper frontend portfolio, and a personal website. Finding a job should’ve been easier. Instead, I spent 18 months struggling to land a role that actually fit me. The competition was simply on another level.

Now, in 2026, it’s even tougher. AI tools have made it easier to apply, build, and present yourself, which also means companies are flooded with candidates. Things like a decent CV or a basic project don’t stand out anymore. A lot of common advice still sounds good, but it doesn’t work the way it used to.

This guide is based on what actually helped me. I’ll walk through the full process – from preparation to interviews to offers – and explain what matters today, and where most developers lose time without realizing it.

I’ve prepared for you a Dev Job Application Toolkit. By my calculation it can save you 40-60 hours.

This toolkit includes:

  • CV and cover letter templates

  • Eight interview checklists

  • List of top 50 remote-first companies

  • Job application tracker spreadsheet

You can get it here: 99cards.dev/toolkit

Table of Contents

1. Mindset & Strategy (Before You Start Applying)

Before you apply anywhere, you need to decide what you actually want. This sounds obvious, but it’s one of the most skipped steps – especially by junior developers. I know this because I skipped it myself.

When you have little or no experience, it’s tempting to think: I’ll apply everywhere and take whatever I get. That approach feels safe, but it’s risky. You can easily end up in a role you don’t enjoy, working on things you don’t care about, and burning out much faster than you expect. A bad first or second job can slow you down more than having no job for a bit longer.

This stage is about setting boundaries before desperation sets in.

Choosing a clear position

First, be honest about the role you’re targeting. UI/UX, frontend, backend, full-stack, mobile – these are not just labels. Companies hire for specific problems, and they want people who are focused, not “a jack of all trades“.

If you present yourself as a generalist without real depth, recruiters don’t see flexibility. Instead, they see risk. Being specific increases your chances, especially for junior and mid-level roles.

Deciding on the work format

Next, decide how you want to work: remote, on-site, or hybrid.

This matters more than people admit. I personally dislike office work, so remote roles are my only option. That decision alone filters out a huge number of jobs – and that’s a good thing. You should make the same call based on how you work best, not on what sounds impressive.

Picking the right company type

Company type affects your daily life more than the tech stack.

Startups, agencies, and large enterprises all work differently. Startups move fast and expect long hours. Enterprises are more structured and predictable. Agencies juggle multiple clients and deadlines. None is inherently better than the others, but one will fit you better than the others.

Understanding the product you’ll work on

Finally, think about what kind of product you want to build.

Some roles mean jumping between projects. Others mean working on one large product for years. Some outsource companies throw dozens of small, unrelated tasks at you. These are very different work styles.

Real story from my experience

I once interviewed for a role where the team lead casually mentioned they build Shopify plugins. I immediately knew it wasn’t for me. I’m interested in web applications, not plugins – and no salary would’ve changed that. I applied anyway because I was desperate, which was a mistake.

Defining your criteria early saves you from this.

Practical checkpoint: if you can’t clearly describe the role, work format, company type, and product you want, you’re not ready to apply yet.

Creating a job search plan

Once you know your direction, turn the job search into something structured. Without a plan, it becomes emotional and inconsistent.

A search plan is just a set of rules you follow regardless of mood.

Plan weekly, then break it into daily goals. For example: apply six days a week, with a target of 90 applications per week. That’s 15 per day.

At first, these numbers are guesses. That’s normal. After a week or two, you’ll see what’s realistic. Maybe 15 quality applications is too much, and 6–8 is sustainable. That’s not failure, that’s data. Adjust and keep going.

Remember: the goal isn’t to hit an impressive number. It’s to stay consistent without burning out.

The second part of the plan is tracking. Use something simple, like a spreadsheet. For each application, note the date, the company, and the current status: sent, rejected, HR interview, technical interview, offer.

b7f84450-fc63-458e-a6f8-8ad7001028aa

This gives you two benefits. First, you don’t lose track of where you’ve applied. Second, over time, you start seeing patterns. You can tell how many applications turn into interviews, where things usually break down, and what might need fixing – your CV, your targeting, or your interview prep.

You can download my free job application tracker spreadsheet here.

Practical checkpoint: if you can’t say how many applications you send per day or where they usually fail, you’re guessing – not managing – your job search.

2. Skill Readiness and Gap Analysis

Before you send your first application, you need to make sure your skills actually line up with what companies are hiring for right now. This stage is about facing reality – not in a negative way, but in a useful one. You’re trying to match your current level to the level the market expects for the role you want.

A good place to start is job descriptions. Pick a few major job boards and scan real openings for your target position. What matters is volume and focus. Look at 10, 20, or even 30 listings for the same role, not random ones. Specificity is critical here.

As you read through them, patterns start to show up. The same technologies appear again and again. At this stage, using AI to summarize requirements can save time, as long as you’re still doing the thinking. The goal is to spot common ground faster, not to outsource judgment.

What you’re looking for is a simple structure.

First, identify the core skills. These are non-negotiable. For a frontend role, that’s usually JavaScript, a framework like React, and a styling solution such as Tailwind. If you’re weak in one of these, that’s a real blocker, not something to “fix later.”

Next, identify two or three nice-to-have skills. These depend on the role and the company type. Agencies often value things like Framer Motion for polished UI work. Product companies may care more about performance or accessibility. These skills won’t always block you, but they can separate you from similar candidates.

Finally, choose at least one adjacent skill. Something that isn’t your main focus but is expected in any professional setup. Git is the most common example. Missing these often leads to quiet rejections – no feedback, just silence.

Once you have this list, it’s time for an honest audit. Don’t rely on passive learning or gut feeling. Test yourself. Use flashcards for concrete concepts (you can this tool for flashcards: 99cards.dev). Answer open-ended questions without notes. Build a small, focused project that forces you to use the skill without guidance.

The outcome of this stage should be clear. You’ll know where you’re solid, where you’re shaky, and where you’re not ready at all. From there, the job is simple: strengthen weak spots until you’re roughly at market level for your target role.

Real story from my experience

I once saw an attractive front-end web developer/web designer position that required Tailwind CSS for styling. In application company required to list two websites with Tailwind CSS in use. At that moment I had none. And I couldn’t apply. Pity.

Practical checkpoint: if you can’t clearly name your core skills, nice-to-haves, and weakest areas, you’re guessing where you stand – and the market won’t guess in your favor.

3. Portfolio Preparation (Critical Stage)

Your portfolio is simply a list of projects you’ve completed. But where and how you present that list matters a lot more than most developers think.

In my experience, the best place for a portfolio is a personal website (here is mine: https://ilyasseisov.com/). It gives you full control. You decide the structure, the wording, the tone, and the visuals.

Some developers prefer a very minimal setup. Others go for something more visual, with motion and modern UI. Both approaches are fine. What matters is that the site reflects how you think and what you care about building.

On that website, you should showcase only your best work. Not everything you’ve ever built. One, two, or at most three projects is enough. These should represent what you can do right now, not what you could do a year ago. More projects don’t make you look better – they usually make it harder for someone to see your strengths.

Choosing the right projects is where many people go wrong. Your portfolio projects should be directly related to the role you want.

When I was focusing on building modern, animated websites, I showed projects with strong visuals, animations, and micro-interactions. When I shifted toward SaaS and web applications, I replaced those with real app-style projects. The portfolio should follow your direction, not your history.

Avoid tutorial clones. Even well-made ones. Recruiters see them immediately, and they don’t tell much about how you think or make decisions. Personal or slightly imperfect projects are usually far more interesting than something copied step by step from a course.

For each project, a simple case-study structure works best. Explain what the project is, why it exists, and how you approached it. Show the final result with a live link, so people can actually use it. Code access is optional. Sometimes you don’t want to make everything public, and that’s fine. If a recruiter asks, you can always give access privately to a small group.

Here is example of my case study page: ilyasseisov.com/projects/99films/

Practical checkpoint: if your portfolio doesn’t clearly show what kind of work you want to be hired for, it’s not helping you – no matter how polished it looks.

4. CV / Resume Preparation

Your CV is not a biography. It’s a filtering document. Its job is to help a recruiter understand, in under a minute, who you are, what role you fit, and whether it’s worth moving you forward. Structure and clarity matter more than clever wording.

Header: make it obvious who you are

At the very top, include your full name, your role, and your main technologies. Be specific.
For example: Frontend Web Developer (React, Next JS).

This saves time for recruiters and helps with automated filtering. I also include my email address, and sometimes – in smaller, low-opacity text – my years of experience (for example, 10+ years). It’s a quick signal, not a headline.

Summary: your short positioning statement

Think of the summary as an elevator pitch with context. This is where you explain what you do well and what kind of problems you’re best at solving. Keep it focused. Avoid vague statements like “passionate developer” or “team player.” Say what you build and where you add value.

Work experience: results over responsibilities

This is the most important section.

For each role, include the company name, time period, and position. If it helps, add a link to the company’s website.

When describing your work, focus on accomplishments, not duties. What did you change? What improved because of your work? Metrics matter here.

For example:

Redesigned and coded the UI of a 20+ page web application, resulting in a 16.7% increase in user engagement and a 21.4% reduction in page load time. Worked closely with backend and QA teams. Designed in Figma, implemented with Tailwind CSS and React.

This tells a much clearer story than listing tasks.

Optional sections (only if relevant)

You don’t need to include everything — only what supports your candidacy.

  • Education: useful if it’s related (computer science, software engineering, and so on)

  • Personal projects: include only if they align with the role you’re applying for

  • Interests or hobbies: optional, but can create a human connection if they’re meaningful

  • Languages: valuable in a global job market

If a section doesn’t strengthen your position, leave it out.

Length and customization

A rough rule: around one page per 10 years of experience.

More important than length is relevance. Ideally, you should have a solid base version of your CV, then slightly adjust it for specific roles. This small effort often leads to a much higher response rate.

Format and tools

Don’t add a photo. It doesn’t help, and in many cases, it hurts.

Always send your CV as a PDF. This avoids layout issues and font problems.
For tools, I prefer Figma because it gives full control over layout and visuals. If that feels like overkill, Google Docs works just fine.

Create a first version, then iterate over time. Add new skills, remove outdated ones. This is normal. My current CV is version six – and it took years to get there.

Before sending your CV, run it through an ATS checker. Many companies use automated systems before a human ever sees your résumé. If the machine can’t read it properly, it won’t matter how good the content is.

You can check out my proven CV template here. It's free to download.

Practical checkpoint: if a recruiter can’t understand your role, level, and strengths in 30–60 seconds, your CV needs simplification – not more detail.

5. Cover Letter

A cover letter is short, focused, and very intentional. It’s not a repeat of your CV – it’s your chance to explain why you’re a great fit for this specific role and this specific company.

What a cover letter is (and isn’t)

A web developer cover letter should be 200–300 words max. Its main goal is to connect your skills and experience to the company’s needs in a more personal way than a résumé can.

Think of it as a bridge between:

  • what you can do (CV)

  • and why they should care

Step 1: Research before writing anything

Never write a generic cover letter.

Before you start:

  • Read the job description carefully

  • Look up the company, their product, and their values

  • Try to find the recruiter or hiring manager’s name (LinkedIn helps a lot)

Then:

  • Pick one strong “crowning achievement” – a project or result that clearly shows your value

Step 2: Header and greeting

Keep it clean and professional.

Header should include:

  • Full name

  • Email + phone

  • Location (city, country/state)

  • Link to your portfolio or personal website (very important for devs)

Greeting:

  • Use “Dear [Name]” or “Dear [Team Name] Team”

  • Avoid “To whom it may concern” — it feels lazy and generic

Step 3: Strong, short introduction

Your intro should be 2 sentences max.

Include the exact role you’re applying for and a quick hook – why this company or product caught your attention.

Example ideas:

  • A product they built

  • A mission you align with

  • A tech stack you’re excited about

Step 4: The body — tell a clear story

This is the core of your cover letter.

Focus on technical skills (HTML, CSS, JavaScript, React, Node.js, and so on) and real impact, not just tools.

Use numbers whenever possible:

  • “Improved performance by 30%”

  • “Reduced load time by 2 seconds”

A great structure here is: Problem → Solution → Impact

Also don’t forget that soft skills matter: communication, problem-solving, teamwork are important. Companies hire people, not just code writers.

Step 5: Adjust for your role level

What you emphasize depends on your profile:

  • Front-end → UI, UX, responsiveness, animations, browser support

  • Back-end → APIs, databases, scalability, performance

  • Full-stack → end-to-end ownership, deployment, architecture

  • Entry-level / junior → personal projects, bootcamps, learning speed, motivation

If you lack experience, that’s okay. Show potential and direction.

Step 6: Closing + call to action

Wrap it up confidently. Reconfirm your interest in the role, briefly restate the value you bring, and add a soft CTA like being open to an interview or discussion.

End with:

  • “Sincerely” or “Best regards”

  • Your name

Step 7: Formatting and final checks

Details matter here.

  • Use the same font as your CV

  • Stick to clean, modern fonts (Plus Jakarta Sans, Inter, DM Sans, etc.)

  • Keep margins simple and spacing readable

  • Always send as a PDF

  • Proofread carefully – mistakes here hurt more than missing skills

Practical checkpoint: If your cover letter could be sent to 10 different companies without changes, it’s not good enough.

You can check out my cover letter template here. You can have it for free.

6. LinkedIn (Turn Your Profile Into a Recruiter Magnet)

LinkedIn shouldn’t be just an online CV. For a web developer, it should work like a high-converting landing page that brings recruiters to you, even while you sleep.

Below is a practical, step-by-step approach, from fixing the basics to getting real inbound opportunities.

Step 1: Get the Basics Right

Before optimizing content, make sure your profile looks clean and professional.

  • Turn off profile update notifications: Go to Settings & Privacy and disable updates before editing. No one needs to see you fixing typos.

  • Create a custom LinkedIn URL: Use something like linkedin.com/in/yourname-dev. It helps with SEO, looks cleaner on your CV, and improves response rates.

  • Profile photo matters a lot: Use a clear, recent headshot. Face should take ~60% of the frame, clean background, friendly expression.

  • Add a custom banner: Don’t leave the gray default. Use Canva to add something simple: your tech stack, role, or personal brand.

Step 2: LinkedIn SEO (So Recruiters Can Find You)

If you’re not optimized for keywords, you’re basically invisible.

Pick your target role – for example, Frontend Developer, React Engineer, Full-Stack Developer

Then repeat that keyword in 4 places:

  • Headline

  • About section

  • Job titles

  • Experience descriptions

Then make sure you write a strong headline (this is very important). Here's the formula:
[Role] + [Main Tech] + [Value]

Example:
Full-Stack Developer | React, Next.js | Building scalable web apps for startups

Step 3: Treat Your Profile Like a Landing Page

Once someone clicks your profile, you need to convert that visit.

About section = your story

Write like a human, not a robot. Explain why you code, what problems you solve, your experience level, and your core stack

Experience = impact, not duties

Don’t list responsibilities. Show results with numbers.

❌ “Built dashboards”
✅ “Built a React dashboard that reduced load time by 30% for 5,000 users”

Skills section matters more than you think

Add at least 5 relevant skills (JavaScript, React, Git, TypeScript, and so on). Profiles with multiple skills get way more profile views and connections.

Step 4: Show Proof (This Is Huge for Developers)

Words are good – but proof is better. Here's how you can show proof:

Add your portfolio website, a linke to your GitHub profile, and live projects or demos.

Ask for recommendations

These can be really helpful, and some companies require them. You can reach out to tech leads, managers you've worked with, or clients (among others).

Recommendations add massive trust.

Pro tip: offer to write one in return.

Step 5: Get More Visible

This is how you go from “searching” to being approached.

Post occasionally

You don’t need to be an influencer. But post something once a month could invite some people to see your page.

Network with intention

Networking is a skill. Follow devs and tech creators, engage with posts (comments > likes), and connect with engineers inside companies you like.

Turn on “Open to Work”

You can make it visible only to recruiters. This is a strong signal that you’re ready for interviews.

Practical checkpoint: If your LinkedIn profile still looks like a copied résumé, you’re leaving opportunities on the table. Treat it like a product page – clear message, strong proof, and easy next step.

And here's a tips: Make sure all information you list at your LinkedIn profile is true. Especially your full name and location. Sometimes LinkedIn admins may ask you to verify it with your real ID.

7. Job Search & Application Strategy

Up to this point, everything you’ve done was preparation. Now you’re ready for the real game: finding jobs and applying the smart way.

Let's start with where to find Developer Jobs.

There isn’t just one correct source. The best strategy is to combine several.

1. Job Boards (Fast but Competitive)

There are two main types of job boards:

Open Job Boards

Examples: LinkedIn, Indeed.

  • ✅ You can apply immediately

  • ❌ Competition is extremely high

  • ❌ Many applications never get seen

These are good for volume, but don’t expect miracles.

Vetted Platforms

Examples: Turing.com, similar invite-only platforms

How it usually works:

  1. Application review

  2. Automated tests or questionnaires

  3. Timed live task (90–120 minutes)

  • ❌ Takes time and effort upfront

  • ✅ Much lower competition afterward

  • ✅ Higher chance of real interviews

If you pass, you enter a smaller talent pool, which is a big advantage.

💡
I was often invited to interviews by companies at Turing.com

2. Company Career Pages (Often Overlooked)

Many companies hire directly through their own websites. Big companies often have dedicated career pages. These may have fewer applicants compared to job boards, and they're usually more serious about hiring.

If you already like a company, check their site first.

3. Startups, Agencies & Communities (Hidden Gold)

This is where many developers get jobs without competing with hundreds of applicants.

Agencies

Find them on award sites, directories, or portfolios.

  • Visit their websites

  • Collect emails

  • Send direct, personalized messages

Startups

Use platforms like Product Hunt.

  • Find early-stage startups

  • Reach out directly via email or LinkedIn

Telegram Groups (Very Underrated)

Many dev job groups exist but aren’t publicized much.

  • Jobs are posted directly by founders or managers

  • You can DM the person first, ask if you’re a fit

  • Attach CV + portfolio

  • If they say yes, then apply

This alone can save you weeks of wasted applications.

Here is a list top 50 remote first companies. These establishments always in search of great talent.

Application Strategies (Choose Wisely)

There are three main approaches.

1. Mass Application (Spray & Pray)

  • Easy Apply, Easy Apply, Easy Apply

  • 20–30 applications per hour

Reality check:

  • ❌ Massive competition

  • ❌ Very low response rate

Good for filling numbers – not great for quality.

2. Sniper Application (High-Conversion)

This is the most effective method.

How it works:

  • Pick a specific company and role

  • Research:

    • Product

    • Team

    • Tech stack

  • Customize:

    • CV

    • Cover letter

  • Try to:

    • Talk to employees

    • Ask for a referral

  • ❌ Slower (1–2 applications/day)

  • ✅ Much higher response rate

  • ✅ Often leads directly to interviews

If you want fewer rejections and better offers, this is it.

3. Networking (Warm Opportunities)

This is the most natural and underrated approach, and there are a couple ways of going about it.

You can focus on offline experience, like:

  • Local meetups

  • Developer groups

  • Tech events

When people know you personally, jobs often come to you.

You can also try online methods, like:

  • Discord communities

  • Reddit

  • Twitter / LinkedIn tech circles

You can share that you’re job hunting, DM people directly and get referrals without formal applications.

This is warm outreach, not cold applying.

Track Everything (Very Important)

Just like mentioned earlier:

  • Set weekly & daily application goals

  • Adjust them to your real pace

Make sure you track the date, company, and status (sent, rejected, interview, offer). A simple spreadsheet is more than enough.

Practical checkpoint: Don’t rely on just one channel. Combine job boards + direct outreach + networking, track your efforts, and focus more on quality than pure volume.

There is a very useful job application tracker I use when applying to jobs. It helps you to see the entire picture of your progress. You can download it here.

8. Technical Interview Preparation

The technical interview is not a normal conversation — it’s closer to an exam + live performance. You’re not just talking about your skills; you’re expected to prove them in real time.

Step 1: Strong Technical Foundation

1. Master One Programming Language

Pick one main language (JavaScript, Python, Java, C++, and so on) and know it really well.

  • Syntax should be automatic

  • You shouldn’t struggle with basics during interviews

  • This lets you focus on problem-solving, not syntax

2. Data Structures & Algorithms (Must-Have)

You should clearly understand:

  • Arrays & strings

  • Hash tables

  • Stacks & queues

  • Linked lists

  • Trees & graphs

  • Heaps

Important: don’t just know how, know why. For example: why a hash table gives average O(1) lookup time.

3. Real Side Projects

Have projects that match the level of the job you want, that are built from scratch, that use real logic, not tutorial clones, and be ready to walk through architecture, decisions, and trade-offs.

This often shifts the interview from grilling to conversation.

Step 2: Pre-Interview Strategy (Once Interview Is Scheduled)

Now it’s about targeted prep.

Résumé Deep-Dive

Be ready to explain everything on your CV.

  • Every framework

  • Every project

  • Every tool

If you listed it, you must defend it.

Behavioral Answers (STAR Method)

Use STAR:

  • Situation

  • Task

  • Action (most important – what you did)

  • Result

Use it for bugs you fixed, conflicts in teams, technical challenges, and failures and lessons learned.

Step 3: How to Act During the Technical Interview

This part matters as much as the solution itself.

1. Read & Rephrase

Read the task and repeat it in your own words. This shows clarity and avoids misunderstandings.

2. Clarify Everything

Ask about:

  • Input format

  • Output format

  • Constraints

  • Edge cases

Good engineers never assume.

3. Think Out Loud

Before coding, explain your approach, start with a brute-force solution, then optimize it. Interviewers care about how you think, not just the final answer.

4. Code Like a Professional

While coding, speak your thoughts, use clear variable names, and teat it like pair programming, not an interrogation

5. Test Your Code

When finished, walk through the code step by step, use example inputs, and try to catch bugs yourself. Debugging your own code is a huge positive signal.

6. Explain Complexity

Always finish with time complexity and space complexity.

Short, clear, confident.

Step 4: Closing the Interview Strong

Ask Smart Questions

When you're wrapping up, make sure you ask smart questions to show your genuine interest and thoughtfulness.

Ask about:

  • Tech stack

  • Architecture

  • Development process

  • Team collaboration

Avoid salary or benefits here – that’s for HR.

Send a Follow-Up

Within 24 hours, thank them and show appreciation.

If you realized you made a mistake, you can briefly explain the correct approach – this shows growth mindset.

Learn From Every Interview

Even failed interviews are data. After each one, ask yourself:

  • Where did I get stuck?

  • What topic do I need to improve?

💡
Interviewing is a skill. The more reps you do, the better you get.

Practical checkpoint: You don’t pass technical interviews by luck. You pass them by deep fundamentals, structured thinking, and practice.

9. HR and Behavioral Interview

The HR / behavioral interview is not just a formality. Very often, this round decides whether you move forward or not.
Unlike technical interviews, this one is about who you are, how you communicate, and whether the team can work with you long-term.

Step 1: Pre-Interview Research (Do Your Homework)

Before the interview, go deeper than your CV.

Research the company

Learn about their mission and values, their product or service, and any recent news, releases, or updates involving them.

This helps you sound intentional, not generic.

Study the job description

Make sure you highlight your soft skills and responsibilities, and then prepare 2–3 real examples that match those requirements.

Build a story bank

Prepare 8–10 short stories from your experience that demonstrate:

  • Solving a problem

  • Working in a team

  • Handling conflict

  • Taking ownership

These stories are your proof. Much better than buzzwords.

Step 2: Use the STAR Method (Always)

Remember the STAR method we talked about above? Use it here, too.

Also, think out loud. HR wants to hear how you reason, not just the final answer.

And practice explaining technical things without jargon. HR people are usually non-technical.

Step 3: Common HR Questions (How to Answer)

“Tell me about yourself”

Keep it to ~2 minutes.

Focus on your current role or level, your main tech stack (for example, JavaScript, React, SQL), and where you want to grow next.

Skip personal life unless asked.

Strengths

Pick role-relevant strengths here and back each one with a quick example.

Example:

“I’m strong at ownership. In my last role, I took responsibility for…”

Weaknesses

This is a tough one. So be honest, but smart. Show self-awareness + improvement, and avoid clichés like “I’m a perfectionist”.

Good structure:

  • Real weakness

  • What you’re doing to improve it

Step 4: Teamwork, Conflict & Feedback

Web development is teamwork-heavy, so expect these.

  • Conflicts

    • Don’t blame others

    • Focus on communication and resolution

    • Show maturity and accountability

  • Code reviews & feedback

    • Treat feedback as growth

    • Show you don’t take criticism personally

  • Mistakes

    • Admit them

    • Explain how you fixed the issue

    • Share what you learned

This signals professionalism and emotional intelligence.

Step 5: Closing the Interview + Salary Questions

Always ask questions

Good examples:

  • What does success look like in the first 3 months?

  • How does the team collaborate?

  • What do you personally enjoy about working here?

Saying “I have no questions” is a bad signal.

Salary expectations

If possible, avoid giving a number too early.

If pushed, give a range, not a single number. And make sure you base it on market research. Also, say it’s negotiable. All this keeps leverage on your side.

Step 6: After the Interview (Don’t Skip This)

Similar strategies here:

  • Send a thank-you email within 24 hours

  • Thank them for their time

  • Reconfirm your interest

Simple, polite, professional.

Practical checkpoint: Technical skills get you noticed. Behavior, communication, and attitude get you hired.

Tip: Before EVERY interview even a first one I always contact HR or recruiter and ask what should I prepare for the interview round. Surprisingly, almost every time I get specific directions.

I always use interview checklist when I prepare for one. It helps you remember all critical points. You can download it here.

9. Salary Negotiation and Job Offers

Congrats — getting an offer means you already won half the battle. Now comes the part where many developers make costly mistakes: accepting too fast or negotiating poorly.

Let’s break this down step by step.

1. When You Receive an Offer: Pause First

When you hear “We’d like to make you an offer”:

  • Say thank you

  • Show excitement

  • Do NOT accept immediately

This is very important.

What to say instead:

  • Ask for the offer in writing

  • Request 24–48 hours (sometimes up to a week) to review it

This is completely normal and professional. The pause helps you move from emotions to logic.

2. Look at Total Compensation (Not Just Salary)

Many developers only look at base salary, but that’s a mistake.

Check the full package for things like:

  • Base salary

  • Health insurance (medical, dental, vision)

  • Retirement plans (401k, matching, vesting period)

  • Equity (stock options / RSUs)

  • Bonuses (sign-on or performance)

  • Remote / hybrid flexibility

  • Equipment budget

  • Learning budget

Sometimes a lower salary + great benefits is actually the better deal.

3. Salary Negotiation Rules (Very Important)

Rule #1: Don’t Give the First Number

If possible, avoid saying a salary number first.

Why? Because employers will anchor low, and you lose leverage immediately.

If asked early, say something like:

“Right now I’m focused on finding a strong mutual fit. I’m open to a fair market offer once we’re aligned.”

If You MUST Give a Number

Give a range, not a single number. Your ideal salary should be at the lower end of that range

4. Advanced Negotiation Tips (Most Devs Skip This)

Negotiation Is Expected

About 80%+ of companies expect negotiation. It doesn’t make you difficult – it makes you look confident.

Use Other Offers (If You Have Them)

If you have another offer, be honest and respectful about it.

Example:

“You’re my top choice, but I have another offer that’s slightly higher. Is there room to adjust?”

Negotiate Non-Money Items

If salary is capped, try asking instead for extra vacation days, a sign-on bonus, a learning budget, or a faster salary review (after 6 months).

Managers often have more flexibility here.

5. Final Step: Close Everything Properly

Before accepting:

  • Get everything in writing

  • Read the contract carefully

  • Check:

    • Job title

    • Salary & bonuses

    • Notice period

    • Non-compete clauses

In many countries, verbal acceptance can be legally binding. Don't say “yes” unless you are 100% sure.

If you reject an offer:

  • Be polite

  • Thank them

  • Keep the relationship open

You never know when paths cross again.

Practical checkpoint: Your first offer sets the baseline for your future career. Take your time, stay professional, and don’t be afraid to negotiate.

Real story: In 2021 I received a very nice job offer. I liked it. The CEO said: “Here is the salary range: A to B. What would you like?“. I said let’s go with middle point. I always prefer win-win situations.

Conclusion

Getting a web developer job today is not about luck – it’s about strategy, preparation, and consistency. The market has changed. Competition is higher, expectations are clearer, and companies are more selective than ever. But the good news is that developers who approach the process the right way still get hired, again and again.

In this guide, you’ve seen the full journey: defining your direction, preparing your skills, building a strong portfolio, crafting a clear CV and cover letter, optimizing LinkedIn, applying smart, preparing for technical and HR interviews, and finally negotiating your offer with confidence. Each stage matters, and skipping even one can significantly lower your chances.

Remember: job searching itself is a skill. The more intentional you are, the better your results will be. Track your progress, learn from rejections, improve weak spots, and don’t rush the process. One strong offer is worth more than a hundred rushed applications.

Most importantly, don’t underestimate your value. If you’ve put in the work, you deserve a role that fits your skills, goals, and lifestyle.

I wish you the best of luck on your journey. Stay consistent, stay confident, and go get that job 🚀

p.s. if you still haven’t you can get Dev Job Application Toolkit here: 99cards.dev/toolkit

]]> <![CDATA[ How to Prepare for Technical Job Interviews – Based on My Experience Landing a Job ]]> https://www.freecodecamp.org/news/how-to-prepare-for-technical-job-interviews-based-on-my-experience-landing-a-job/ 694c23da6c9dee59dd506fea Wed, 24 Dec 2025 17:33:14 +0000 Hi, I’m Ilyas. I’m a web developer, and this is my story about how I struggled with interviews for a long time and what finally helped me break through. I’ll talk about what failing basic interview questions taught me about recall, preparation, and smarter job searching.

If you’re a junior, mid-level, or self-taught developer who keeps getting rejected and you don’t fully understand why, I hope this helps.

Here’s what I’ll cover:

  1. My 18-Month Job Search Struggle

  2. The Interview Problem I Didn’t Expect

  3. Discovering Active Recall and Flashcards

  4. My Interview Preparation System

  5. The Results

  6. Changing How I Looked for Jobs

  7. Turning My System Into a Small Tool

  8. Lessons I learned

  9. Final Thoughts

My 18-Month Job Search Struggle

For 18 months, I was trying to land a remote or relocation web developer job.

During that time:

  • I applied to more than 1,000 positions

  • I went through around 20–30 interviews

  • I failed most of them

It was exhausting. I felt like I was putting in a lot of effort but getting almost no results. Over time, I started doubting my skills and wondering whether I would ever find a job I’d actually be satisfied with.

What made this even more confusing was that a few years earlier, in 2021, I had found a remote job at a US company in just three weeks – with almost no experience

Something clearly wasn’t working anymore.

real screenshot from one my unsuccessful interviews from Turing.com

The Interview Problem I Didn’t Expect

After dozens of interviews, I noticed a pattern: I wasn’t failing because I couldn’t solve complex algorithm problems or build features under pressure. I was failing on basic technical questions.

Questions like:

  • “What are portals in React?”

  • “Can you explain how an HTTP GET request works?”

These were not hard questions. They were things I had learned before. But during interviews, under pressure, I just couldn’t recall. Or simply I skipped it during preparation because there were no systems in place.

That’s when I realized the real issue: I didn’t have a problem understanding concepts. I had a problem recalling them quickly.

My first instinct was to study more. More tutorials, more articles, more videos.

But passive learning didn’t fix the problem. I still froze during interviews. What I actually needed was a way to train my memory, not just consume information.

Discovering Active Recall and Flashcards

That’s when I came across flashcards and the concept of active recall.

Active recall means testing yourself repeatedly on what you’ve learned instead of just rereading material. You try to answer a question from memory first, then check the answer. This approach has been backed by research for more than a century.

I started practicing small, specific concepts this way, like:

  • React fundamentals

  • JavaScript basics

  • HTTP methods

  • Browser behavior

I repeated them until recalling the answer felt automatic.

This made a huge difference during interviews.

Flashcards help you cut through the noise and actually learn what matters. It's not just about memorizing facts – it's about really understanding, remembering fast, and building a solid base in every concept you study.

So to help you prepare for your interviews, I’ve taken years of experience and scientific learning methods and turned them into a tool and approach that gives you the right info at the right time.

My Interview Preparation System

Once I found the right learning method, I built a simple system around it.

Step 1: Ask What to Prepare For

Instead of guessing what to study, I started asking recruiters directly:

“What topics should I prepare for the technical interview?”

Surprisingly, many of them replied with a clear list, which helped me focus only on what actually mattered and avoid over-preparing random topics. In my experience, many HR reps are quite helpful to job applicants.

For example, when I applied for a position as a Frontend Web Developer in React, the HR specialist advised me to focus mainly on React and JavaScript. So I prepared for all the popular questions around hoisting (JS), the event loop (JS), how react works under the hood, what props are and how they work, and so on.

Overall, that interview went well – but when I got a question on React Portals, I couldn’t explain it properly. And so I didn’t get the position. But I don’t blame myself for this one, as that’s a very rare topic. 😊

I also applied for another Front End Developer role where the HR specialist advised me to prepare mainly for questions about GSAP, Framer Motion, and React/Next JS. This made sense, as the company mainly builds modern animated websites.

In my interview, the theory round went well, but I failed the take home assignment. I realized then that I didn’t have enough skills in these areas.

At another company, I asked HR about the cultural interview, which was the last round. The rep said: ”No worries, all the hard work is done from your side. Prep for just a human dialog.”

And for the last application I submitted (and after which I actually got the job offer), the HR specialist told me to strongly prepare for CSS – especially Flexbox and Grid. This made sense, as the position was for an HTML markup developer. And so I practiced all the ins and outs for these topics, even the more rare ones.

I use the same approach for each round of interviews.

Step 2: Use Flashcards (With AI Carefully)

I used ChatGPT to generate flashcards for each topic and reviewed them daily.

One important thing I learned: AI can be wrong sometimes. To reduce mistakes, I started adding links to official documentation in my prompts so the answers were grounded in reliable sources.

I kept sessions short and consistent. That consistency mattered more than long study sessions.

AI mistakes was the reason I created 99cards.dev

Here is the prompt I use in ChatGPT:

You are a web development expert with 20 years of experience. Your task is to help me to prepare for the interview.

Prepare 10 flashcards on CSS Flexbox topics. Format one question with four answers. One answer is correct.

You're going to serve all the questions one by one. After I answer, you give me feedback and then give me the next question.

Note that you should tweak your prompts for your needs, and based on what you need to review.

You can experiment with various factors, such as:

  • Difficulty: beginner or advanced

  • Specificity: from vague (for example: I want to practice with CSS) to highly specific (for example: I want to practice with the flex property in CSS Flexbox)

  • Number of questions: sweet spot is between 10 and 20

  • Add context: good practice is to add links to official docs, as it decreases the chances of AI hallucination

Here is a typical flashcard created by ChatGPT:

flashcard created with ChatGPT

If you provide an answer, you’ll get feedback like this:

feedback by ChatGPT

The Results

After a few weeks, interviews felt very different.

I was calmer. I answered basic questions without panicking. I could explain concepts clearly and confidently.

In my final interview process, I passed four rounds in a row and scored 95% on the technical test.

Soon after, I received an offer: $5,500 per month and a paid relocation package for my family and me.

For the first time in a long while, my effort finally matched the results.

screenshot of job offer

Changing How I Looked for Jobs

About six weeks before getting the offer, I also changed where I searched for jobs.

Instead of relying only on large job platforms, I started using smaller communities like Telegram job groups.

This helped for two reasons:

  1. Less competition: many smaller companies post roles there with fewer applicants

  2. Direct communication: I could message recruiters before applying

Before submitting an application, I would ask:

“I saw this position. Here’s my CV and LinkedIn. Am I a good fit?”

If the answer was yes, I applied. If not, I moved on immediately.

This saved me a lot of time and energy.

job groups in Telegram

Turning My System Into a Small Tool

While preparing for interviews, I created thousands of flashcards for myself. Managing them in notes became difficult, so I eventually turned them into a small tool called 99cards.dev.

It’s simply a collection of fact-checked web development flashcards grouped by topic, based on the same approach that helped me stop failing basic interview questions.

Here are some screenshots from the app:

99cards.dev - UI screenshots

Lessons I Learned

Here are a few takeaways from this experience:

  • Failing interviews doesn’t always mean you lack skills

  • Passive learning is not enough for interview prep

  • Being able to recall basics quickly matters a lot

  • Job searching is a skill, not just a numbers game

  • Consistency beats cramming every time

Final Thoughts

If you’re struggling with interviews right now, especially as a junior, mid-level, or self-taught developer, don’t assume you’re bad at what you do.

In my case, the problem wasn’t effort or talent. It was preparation and approach.

I also created a free interview checklist based on my experience, covering HR, technical, behavioral, system design, live coding, take-home tasks, algorithms, and cultural fit.

I hope this story saves you some time and stress.

You’re often just one good interview away.
— Ilyas

]]>