Are you preparing for technical interviews at top tech companies? If so, you’ve probably heard about the famous Blind 75 list. This curated collection of coding problems has become the gold standard for interview preparation, helping thousands of engineers land jobs at companies like Google, Amazon, and Meta.

In this comprehensive guide, I’ll break down everything you need to know about the Blind 75 list, why it’s so effective, and how to use it strategically for your interview prep.

What is the Blind 75 list?

The Blind 75 list is a carefully curated collection of 75 coding problems that cover the most essential data structures and algorithms concepts tested in technical interviews. Originally shared on the Blind app (hence the name), this list has gained massive popularity because it focuses on quality over quantity.

Unlike other resources that overwhelm you with hundreds of problems, the Blind 75 list strategically selects problems that:

• Cover fundamental programming patterns
• Appear frequently in real interviews
• Build upon each other to reinforce learning
• Provide maximum learning impact with minimal time investment

Why the Blind 75 list is so effective

1. Curated for maximum impact

Every problem on the Blind 75 list serves a specific purpose. You won’t waste time on obscure problems that rarely appear in interviews. Instead, you’ll focus on patterns and techniques that interviewers actually test.

2. Balanced difficulty progression

The list includes problems ranging from easy to hard, allowing you to build confidence while gradually tackling more complex challenges. This balanced approach prevents frustration and maintains steady progress.

3. Comprehensive topic coverage

The Blind 75 list covers essential topics including:

• Arrays and strings
• Linked lists
• Trees and graphs
• Dynamic programming
• Binary search
• Sorting algorithms
• Hash maps
• Stack and queue operations

4. Time-efficient preparation

With only 75 problems, you can realistically complete the entire list in 4–6 weeks with consistent practice. This focused approach is perfect for busy professionals who need efficient interview prep.

Essential problems from the Blind 75 list

While I can’t share premium solutions here, let me highlight some key problem types you’ll encounter:

Array problems

• Two sum: Finding pairs that add up to a target
• Maximum subarray: Understanding dynamic programming basics
• Product of array except self: Working with array manipulation

Tree problems

• Maximum depth of binary tree: Fundamental tree traversal
• Valid binary search tree: Understanding BST properties
• Lowest common ancestor: Advanced tree algorithms

String problems

• Valid anagram: Hash map applications
• Longest palindromic substring: String manipulation techniques
• Group snagrams: Complex data structure usage

These problems form the foundation of most technical interviews and teach you reusable patterns you’ll apply to similar questions.

How to Approach the Blind 75 List Strategically

Week 1–2: Foundation building

Start with easier problems focusing on arrays, strings, and basic data structures. Don’t rush, understanding the patterns is more important than speed.

Week 3–4: Tree and graph exploration

Dive into tree traversals, binary search trees, and basic graph algorithms. These concepts appear frequently in interviews.

Week 5–6: Advanced topics

Tackle dynamic programming, complex algorithms, and harder problems. By now, you should recognize common patterns and solve problems more efficiently.

Daily practice tips

1. Solve 1–2 problems daily rather than cramming
2. Write solutions by hand first before coding
3. Time yourself to simulate interview pressure
4. Review solutions even when you solve problems correctly
5. Practice explaining your approach out loud

Common mistakes to avoid

1. Jumping to hard problems too early

Resist the temptation to tackle difficult problems before mastering the basics. Build your foundation systematically.

2. Memorizing solutions instead of understanding patterns

Focus on understanding the underlying patterns and techniques rather than memorizing specific solutions.

3. Skipping the “easy” problems

Easy problems teach fundamental patterns you’ll need for harder questions. Don’t skip them thinking they’re beneath you.

4. Not practicing code implementation

Understanding the algorithm is just the first step. Practice writing clean, bug-free code under time pressure.

Why Front End engineers should master the blind 75 list

As a front end engineer, you might wonder why data structures and algorithms matter for your role. Here’s the reality: most tech companies use the same interview process for all engineering roles, regardless of specialization.

Companies like Google, Meta, and Amazon expect front-end engineers to demonstrate strong algorithmic thinking. The Blind 75 list prepares you for these standardized technical rounds while building problem-solving skills that make you a better engineer overall.

Maximizing Your Blind 75 Practice

Choose the right platform

While you can find the Blind 75 list on various platforms, having access to quality solutions and test cases makes a significant difference. Look for platforms that offer:

• Solutions in your preferred programming language (JavaScript/TypeScript for front-end engineers)
• Automated testing to verify your solutions
• In-browser coding environments
• Detailed explanations from experienced engineers

Focus on JavaScript/TypeScript implementation

If you’re a front-end engineer, practicing in JavaScript or TypeScript gives you an advantage. You’ll be more comfortable with the syntax during interviews and can leverage language-specific features effectively.

Track your progress

Keep a spreadsheet or use a platform that tracks your progress through the Blind 75 list. Seeing your advancement helps maintain motivation during challenging periods.

The bottom line: Your path to interview success

The Blind 75 list has earned its reputation as the most effective resource for technical interview preparation. It’s not about memorizing 75 solutions, it’s about understanding the fundamental patterns that appear in thousands of possible interview questions.

By working through this curated list systematically, you’ll develop the algorithmic thinking and coding skills needed to excel in technical interviews at any top tech company.

Remember, consistency beats intensity. Dedicate time daily to work through these problems, focus on understanding rather than memorization, and practice implementing clean solutions under time pressure.

Ready to start your blind 75 journey?

The Blind 75 list is your roadmap to technical interview success, but having the right resources makes all the difference. You need quality solutions, proper test cases, and an environment designed specifically for interview preparation.

Want to practice the Blind 75 list with solutions specifically tailored for front-end engineers? Check out GreatFrontEnd’s Blind 75 collection, where you’ll find every problem solved in JavaScript and TypeScript by ex-interviewers from top tech companies.

With automated test cases, in-browser coding, and detailed explanations, you’ll master these essential problems faster and more effectively than studying alone.

Start your preparation today, your dream job is waiting.

Stop getting rejected. Here’s how to write a CV that makes hiring managers want to meet you.

Let me guess. You’ve been sending out your CV for weeks, maybe even months, and you’re barely getting any responses.

You know you’re a good developer. You can build beautiful, responsive websites. You understand JavaScript inside and out. But somehow, your CV isn’t opening doors.

Here’s the brutal truth: Most front end developer CVs are terrible. They either look like they were designed in 1995, or they’re so fancy that applicant tracking systems (ATS) can’t even read them.

I’ve reviewed hundreds of CVs from front end developers at all levels, and I’ve noticed some patterns. The developers who get interviews, especially at top companies, follow specific rules that most people don’t know about.

As someone who’s helped thousands of developers improve their CVs and land jobs at companies like Google, Meta, and Amazon, I’m going to share exactly what works and what doesn’t.

Why your current CV isn’t working

Before we dive into solutions, let’s talk about why most front end developer CVs fail:

Problem #1: They look unprofessional You’re a front end developer. If your CV doesn’t look good, hiring managers assume you can’t design good user interfaces either.

Problem #2: They’re not ATS-friendly 60% of large companies use applicant tracking systems to filter CVs before humans even see them. Fancy designs often get rejected automatically.

Problem #3: They don’t show impact Most developers just list their job duties instead of showing the results they achieved.

Problem #4: They include irrelevant skills Adding every JavaScript library you’ve touched once makes you look unfocused, not versatile.

Let’s fix these problems one by one.

The foundation: CV structure that works

Your CV should follow this exact structure:

1. Header (Name, contact info, portfolio link)
2. Professional Summary (2–3 lines max)
3. Work Experience (The biggest section)
4. Skills (Carefully curated)
5. Projects (Portfolio highlights)
6. Education (Keep it brief)

Length rule: One page if you have less than 5 years of experience. Two pages maximum, no matter how senior you are.

Making your CV look professional (without breaking ATS)

Here’s the secret: Your CV needs to look good to humans but simple enough for machines to read.

Do this:

• Use a single-column layout
• Stick to standard fonts (Arial, Calibri, or Garamond)
• Use consistent formatting throughout
• Save as PDF for submission
• Use bullet points for easy scanning

Don’t do this:

• Create your CV in Photoshop or Canva
• Use multiple columns
• Add graphics or images
• Use fancy fonts that might not display properly
• Submit as a Word document

Pro tip: Test your CV by copying and pasting the text into a plain text editor. If it looks messy, ATS systems will struggle too.

The work experience section that gets You noticed

This is where most developers mess up. They write boring job descriptions instead of impressive achievements.

Bad example: “Built websites using HTML, CSS, and JavaScript”

Good example: “Built a performant e-commerce website serving 20,000+ monthly users with React and Next.js, achieving 98 Lighthouse score and sub-2-second load times. Increased conversion rate by 15% through UX improvements.”

See the difference? The second example shows:

• Scale (20,000+ users)
• Technology choices (React, Next.js)
• Performance metrics (Lighthouse score, load times)
• Business impact (15% conversion increase)

Here’s what to highlight in your experience:

Performance improvements: “Reduced page load time by 40% through code splitting and lazy loading”

User impact: “Built responsive design system used across 12 product teams, improving development speed by 30%”

Technical achievements: “Migrated legacy jQuery codebase (50,000+ lines) to React, reducing bugs by 60%”

Testing and quality: “Increased test coverage from 30% to 85%, reducing production bugs by 50%”

The skills section that actually helps

Most developers list way too many skills. This dilutes the impact and makes you look unfocused.

The rule: Include only skills that are either:

1. Listed in the job description
2. Critical to front end architecture
3. Widely used or trending
4. Show your breadth without overwhelming

Bad example:

Languages: HTML, CSS, JavaScript, TypeScript, Python, Java, C++, PHP

Technologies: React, Angular, Vue, Svelte, jQuery, Bootstrap, Tailwind, Sass, Less, Webpack, Vite, Parcel, Rollup, Jest, Mocha, Jasmine, Cypress, Selenium, GraphQL, REST, Node.js, Express, MongoDB, PostgreSQL…

Good example:

Languages: HTML, CSS, JavaScript, TypeScript

Technologies: React, Next.js, Tailwind CSS, Jest, Cypress, GraphQL, Webpack

Pro tip: Look at the job description and make sure your skills section includes the technologies they mention (if you actually know them).

Projects that prove your skills

Your projects section is crucial, especially if you’re early in your career or changing jobs. This is where you show off modern technologies and personal passion.

What makes a great project entry:

Clear description: What does it do and why did you build it? Technology stack: What did you use and why? Live links: GitHub repo and deployed version Key achievements: Performance, user feedback, technical challenges solved

Example:

Personal Finance Tracker | React, Node.js, MongoDB

- Built full-stack web app helping users track expenses and set budgets

- Implemented real-time data visualization with Chart.js showing spending patterns

- Added OAuth authentication and secure data encryption

- Live: myfinanceapp.com | Code: github.com/yourname/finance-tracker

Bonus points for:

• Open source contributions
• Projects using technologies the company uses
• Apps that solve real problems
• Code with good documentation and tests

Common mistakes that kill your chances

Mistake #1: Generic professional summary “Experienced front end developer with passion for creating user-friendly websites.”

Better: “Front end developer with 4+ years building scalable React applications. Improved core product performance by 40% at previous role, serving 100k+ daily users.”

Mistake #2: Listing outdated skills Don’t mention jQuery, Flash, or Internet Explorer unless the job specifically requires them.

Mistake #3: No quantifiable achievements Instead of “improved website performance,” write “reduced load time from 8 seconds to 2 seconds.”

Mistake #4: Too much personal information Skip the photo, age, marital status, and hobbies unless they’re directly relevant.

Mistake #5: Ignoring mobile optimization Your CV should look good on phones too. Many recruiters review CVs on mobile devices.

Tailoring your CV for different types of companies

For startups:

• Emphasize versatility and ability to wear multiple hats
• Highlight experience with modern tech stacks
• Show examples of moving fast and iterating

For large corporations:

• Focus on scale and collaboration
• Mention experience with large codebases
• Highlight process improvements and best practices

For agencies:

• Show variety in projects and clients
• Emphasize ability to work under tight deadlines
• Include examples of different industries you’ve worked in

The final checklist

Before sending your CV, make sure you’ve covered these basics:

✅ Contact information is current (especially your phone number)
✅ Portfolio link works and shows your best work
✅ No typos or grammatical errors (seriously, proofread everything)
✅ Consistent formatting throughout the document
✅ Relevant keywords from the job description are included
✅ File name is professional (FirstName-LastName-CV.pdf)
✅ PDF format for consistent display across devices

Ready to land your next front end developer role?

Writing a great CV is just the first step. Once you start getting interviews, you’ll need to prove your technical skills and problem-solving abilities.

That’s where practice makes the difference. At GreatFrontEnd, we help developers prepare for the entire interview process:

✅ Practice real interview questions used at top companies
✅ Build projects that showcase your skills
✅ Learn from detailed solutions written by senior engineers
✅ Master the concepts that actually matter in interviews

Over 34,000 developers have used our platform to prepare for interviews at companies like Google, Amazon, and Meta.

Start practicing front end interview questions →

Remember, your CV is your first impression. Make it count by showing not just what you’ve done, but the impact you’ve made. Focus on results, keep it clean and professional, and always tailor it to the job you want.

What’s worked best for you when writing CVs? Share your tips in the comments below!

Understanding closures is like unlocking a secret superpower in JavaScript. Here’s everything you need to know.

I’ll be honest with you. When I first encountered JavaScript closures, I thought they were some advanced, mystical concept that only senior developers needed to worry about.

Boy, was I wrong.

Closures aren’t just an advanced topic, they’re everywhere in JavaScript. If you’ve ever written an event handler, used a callback function, or worked with React hooks, you’ve already been using closures without even realizing it.

The problem is, most developers never take the time to truly understand what’s happening under the hood. They copy code that works, but when things break or when an interviewer asks them to explain closures, they’re stuck.

After reviewing thousands of JavaScript interview questions and talking to developers at all levels, I’ve realized that understanding closures is what separates developers who just write code from those who truly understand JavaScript.

So let’s fix that. In this article, I’ll explain closures in a way that actually makes sense, show you why they’re useful, and give you the confidence to use them in your own code.

What exactly is a Closure?

Let me start with a definition that doesn’t sound like it came from a computer science textbook:

A closure is a function that remembers variables from the place where it was created, even after that place is gone.

Think of it like a backpack. When you create a function inside another function, that inner function packs a backpack with all the variables it might need from its surroundings. Even if you take that function somewhere else, it still has its backpack with all those variables.

Here’s the simplest example:

javascript
function outerFunction() {
  const message = "Hello from the outside!";
  
  function innerFunction() {
    console.log(message); // This still works!
  }
  
  return innerFunction;
}

const myFunction = outerFunction();
myFunction(); // "Hello from the outside!"

What’s happening here? Even though outerFunction finished running, innerFunction still remembers the messagevariable. That’s a closure.

The “aha!” moment: A real-world example

Let’s look at something you probably see every day, a counter:

javascript
function createCounter() {
  let count = 0;
  
  return function() {
    count++;
    return count;
  };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2
console.log(counter()); // 3

This is where closures get interesting. Each time you call counter(), it remembers the previous value of count. The variable count is “private”, you can’t access it directly from outside, but the inner function can still see it and modify it.

Why is this powerful? You’ve just created a private variable in JavaScript! The count variable can’t be accidentally changed by other parts of your code.

Closures are everywhere (you just didn’t know it)

Remember when I said you’ve probably already used closures? Here are some places you’ve definitely encountered them:

Event Handlers

javascript
function setupButton(name) {
  const button = document.getElementById('myButton');
  
  button.addEventListener('click', function() {
    alert('Hello ' + name + '!'); // 'name' is from the outer scope
  });
}

setupButton('John');

That event handler? It’s a closure. It remembers the name variable even after setupButton finishes running.

React Hooks

If you’ve used React, you’ve definitely worked with closures:

javascript
function Counter() {
  const [count, setCount] = useState(0);
  
  const handleClick = () => {
    setCount(count + 1); // Closure captures 'count' and 'setCount'
  };
  
  return <button onClick={handleClick}>Count: {count}</button>;
}

That handleClick function? Yep, it’s a closure too.

Array Methods

Even simple array methods use closures:

javascript
const numbers = [1, 2, 3, 4, 5];
const multiplier = 3;

const tripled = numbers.map(function(num) {
  return num * multiplier; // 'multiplier' comes from outside
});

Common interview questions about Closures

Here are the questions I see most often in JavaScript interviews:

Question 1: The classic loop problem

“What will this code output, and why?”

javascript
for (var i = 0; i < 3; i++) {
  setTimeout(function() {
    console.log(i);
  }, 1000);
}

Answer: It will print 3 three times, not 0, 1, 2 like you might expect.

Why? By the time the setTimeout functions run, the loop has finished and i is 3. All three functions share the same reference to i.

How to fix it: Use let instead of var, or create a new scope:

javascript
for (let i = 0; i < 3; i++) {
  setTimeout(function() {
    console.log(i); // Now prints 0, 1, 2
  }, 1000);
}

Question 2: Creating multiple functions

“How would you create multiple counter functions that each maintain their own count?”

javascript
function createCounter() {
  let count = 0;
  return function() {
    count++;
    return count;
  };
}

const counter1 = createCounter();
const counter2 = createCounter();

console.log(counter1()); // 1
console.log(counter1()); // 2
console.log(counter2()); // 1 (separate counter!)

Each call to createCounter() creates a new closure with its own count variable.

Why closures matter for your career

Understanding closures isn’t just about passing interviews. Here’s why they’re genuinely useful:

1. Data Privacy: JavaScript doesn’t have built-in private variables, but closures let you create them.

2. Functional Programming: Closures enable powerful patterns like currying and partial application.

3. Module Patterns: Before ES6 modules, closures were the main way to create modules with private and public methods.

4. Better Code Organization: Closures help you write cleaner, more organized code by keeping related data and functions together.

Advanced closure patterns

Once you understand the basics, here are some advanced patterns that’ll make you look like a JavaScript ninja:

The Module Pattern

javascript
const Calculator = (function() {
  let result = 0; // Private variable
  
  return {
    add: function(x) {
      result += x;
      return this;
    },
    multiply: function(x) {
      result *= x;
      return this;
    },
    getResult: function() {
      return result;
    }
  };
})();

Calculator.add(5).multiply(3).getResult(); // 15

Function Factories

javascript
function createValidator(type) {
  const patterns = {
    email: /^[^\s@]+@[^\s@]+\.[^\s@]+$/,
    phone: /^\(\d{3}\)\s\d{3}-\d{4}$/
  };
  
  return function(input) {
    return patterns[type].test(input);
  };
}

const emailValidator = createValidator('email');
const phoneValidator = createValidator('phone');

console.log(emailValidator('test@example.com')); // true

Common pitfalls to avoid

Memory Leaks: Closures keep references to their outer scope, which can prevent garbage collection. Be mindful in long-running applications.

Performance: Creating many closures can impact performance. In most cases, this isn’t a problem, but be aware of it in performance-critical code.

Debugging Confusion: Closures can make debugging trickier because variables might come from unexpected places.

Ready to master javaScript closures?

Understanding closures is just the beginning. If you really want to level up your JavaScript skills, you need to practice with real interview questions and get feedback on your code.

At GreatFrontEnd, we have dozens of JavaScript questions that test your understanding of closures, scope, and other fundamental concepts. You can:

✅ Practice coding directly in your browser — No setup required
✅ Get instant feedback with our automated test cases
✅ Learn from detailed explanations written by senior engineers
✅ Master JavaScript concepts that actually matter in interviews

Start practicing JavaScript closures on GreatFrontEnd →

The difference between a junior developer and a senior developer often comes down to understanding concepts like closures. Don’t just memorize the syntax, understand how it works and why it’s useful.

Your future self (and your interviewer) will thank you.

Have you encountered tricky closure questions in interviews? Share your experience in the comments below!

Getting ready for that front-end interview? Here are the HTML questions you absolutely need to know.

You know that feeling when you walk into a tech interview thinking you’ve got HTML covered, only to get stumped by what seems like a “simple” question about semantic elements or accessibility?

I’ve been there. And after talking to hundreds of developers who’ve interviewed at companies like Google, Meta, and Amazon, I’ve noticed something: HTML questions are often the make-or-break moment in front-end interviews.

Why? Because interviewers use HTML questions to quickly assess whether you understand web fundamentals or if you’re simply copying code from Stack Overflow or generating answers with AI, without real context.

The thing is, most developers spend weeks grinding LeetCode algorithms but barely review HTML basics. Big mistake. I’ve seen brilliant React developers get rejected because they couldn’t explain the difference between section and div.

At GreatFrontEnd, we’ve analyzed thousands of interview experiences and identified the HTML questions that come up again and again. Here are the 10 most essential ones you need to master.

Question 1: Build a simple counter

Why interviewers ask this: It’s the perfect warm-up question that tests your understanding of basic HTML structure, event handling, and DOM manipulation.

What they’re really testing: Can you write clean, semantic HTML? Do you understand the relationship between HTML, CSS, and JavaScript?

The setup is simple: Create a button that shows a number. Every time someone clicks it, the number goes up by one.

Sounds easy, right? But you’d be surprised how many people overthink this or write messy code.

Key things to remember:

• Use semantic HTML elements
• Keep your JavaScript clean and simple
• Think about accessibility from the start

Want to practice this one? Try the Counter question on GreatFrontEnd →

Question 2: Create an accessible accordion

Why this matters: Accordions are everywhere in modern web apps, and building an accessible one requires solid HTML knowledge.

What trips people up: Most developers can make an accordion work, but making it accessible? That’s where things get tricky.

The challenge: Build a component that shows a list of sections. Each section has a title and content. Click the title, and the content expands or collapses.

The accessibility part is crucial:

• Screen readers need to understand what’s happening
• Keyboard navigation must work properly
• ARIA attributes should be used correctly

This question separates developers who just make things work from those who build inclusive experiences.

Practice building an accessible accordion →

Question 3: HTML semantic elements deep dive

The question: “Explain the difference between section, article, aside and div. When would you use each one?”

Why interviewers love this: It reveals whether you understand modern HTML or if you’re still thinking like it’s 2005.

Here’s what they want to hear:

• <div> is for generic containers with no semantic meaning
• <section> groups related content together
• <article is for standalone content that makes sense by itself
• <aside> is for content that’s related but not essential

Pro tip: Think about how a screen reader would interpret your choices. If you’re just using divs everywhere, you’re making the web less accessible.

Question 4: Form validation and accessibility

The scenario: Build a contact form that validates user input and works well for everyone.

Why this comes up: Forms are fundamental to web development, but most developers build forms that are frustrating for users with disabilities.

What makes this tricky:

• Client-side validation vs server-side validation
• Error message placement and association
• Making sure screen readers can navigate smoothly
• Proper labeling of form controls

The basics everyone should know:

• Every input needs a proper label
• Error messages should be associated with their inputs
• Required fields should be clearly marked
• Validation should be accessible and helpful

Build a proper contact form →

Question 5: The box model challenge

The question: “Explain the CSS box model and how box-sizing affects it.”

Why it matters: Understanding the box model is fundamental to CSS layout, but many developers still get confused by padding, borders, and margins.

What they’re looking for:

• Clear explanation of content, padding, border, and margin
• Understanding of box-sizing: border-box vs content-box
• Real examples of when each approach is useful

Common mistake: Explaining the theory but not being able to apply it practically.

Question 6: Responsive images and performance

The challenge: “How would you implement responsive images that load efficiently across different devices?”

Why this comes up: Images are often the biggest performance bottleneck on websites, and handling them properly requires understanding multiple HTML and CSS concepts.

Key concepts to cover:

• The srcset attribute and how it works
• Art direction with the <picture> element
• Loading performance with loading=”lazy”
• Modern image formats and fallbacks

What separates good answers: Mentioning both performance AND user experience considerations.

Question 7: HTML5 APIs and modern features

Typical question: “What are some HTML5 APIs you’ve used, and how do they improve user experience?”

Why interviewers ask this: They want to see if you keep up with web standards and think beyond basic markup.

Strong answers might include:

• Local Storage for offline capabilities
• Geolocation for location-based features
• File API for drag-and-drop uploads
• History API for single-page applications

Pro tip: Don’t just list APIs. Explain when and why you’d use them.

Question 8: Build a data table with accessibility

The task: Create a table that displays user data with proper accessibility features.

Why this matters: Tables seem simple, but making them accessible and usable requires understanding semantic HTML structure.

Key considerations:

• Proper table headers and their association with data
• Caption and summary for screen readers
• Handling large datasets with pagination
• Making tables work on mobile devices

Try building an accessible data table →

Question 9: Custom HTML elements and web components

The question: “How would you create a custom HTML element? What are the benefits and drawbacks?”

Why it’s relevant: Web Components are becoming more important, and this question tests advanced HTML knowledge.

What good answers include:

• Understanding of Custom Elements API
• Lifecycle methods and their purposes
• Shadow DOM and style encapsulation
• When to use web components vs frameworks

Bonus points: Mentioning accessibility considerations in custom elements.

Question 10: Performance and HTML structure

The challenge: “How does HTML structure affect website performance? What techniques do you use to optimize loading?”

Why this matters: HTML isn’t just about structure, it directly impacts how fast your site loads and feels.

Key optimization techniques:

• Critical CSS inlining
• Resource hints like preload and prefetch
• Lazy loading for images and iframes
• Proper script loading with async and defer

Advanced topic: Understanding how the browser parser works and how HTML structure affects rendering.

Ready to ace your HTML interview?

These 10 questions cover the fundamentals that every front-end developer should master. But here’s the thing , knowing the theory is just the first step. You need to practice actually building these solutions.

That’s exactly why we created GreatFrontEnd. Instead of just reading about HTML concepts, you can:

✅ Code directly in your browser — No setup required
✅ Get instant feedback with automated test cases
✅ Learn from detailed solutions written by ex-FAANG engineers
✅ Practice with 90+ HTML questions covering every topic you’ll encounter

The best part? Over 34,000 developers have already used our platform to prepare for interviews at companies like Google, Amazon, and Meta.

Want to see how you’d handle these questions under pressure? Start practicing on GreatFrontEnd →

Remember, HTML might seem basic, but it’s the foundation everything else is built on. Master these fundamentals, and you’ll stand out in any front-end interview.

What HTML questions have you encountered in interviews? Drop a comment below, I’d love to hear about your experiences.

React interviews can be nerve-wracking. You’ve studied the docs, built some projects, and feel confident about your skills. But then you sit down for the coding round, and suddenly your mind goes blank when the interviewer asks you to build a “simple” component.

Here’s the thing , React interviews aren’t just about knowing the syntax. Interviewers want to see how you think, how you structure components, and how you handle real-world scenarios. After helping thousands of developers prepare for their React interviews at GreatFrontEnd, I’ve noticed some patterns in what companies actually ask.

Today, I’m sharing 10 React questions that keep showing up in interviews. These aren’t random coding puzzles , they’re practical components you’ll likely build in your actual job. Master these, and you’ll walk into your next interview with confidence.

Why these questions matter

Before we dive in, let me explain why I picked these specific questions. Each one tests different React concepts that interviewers care about:

• Component structure — Can you break down a problem into logical pieces?
• State management — Do you know when and how to use useState, useEffect?
• Event handling — Can you make components interactive?
• Props and data flow — Do you understand how data moves through React?
• Real-world thinking — Can you build something users would actually use?

Let’s get started.

Beginner level questions

1. Contact form

What it tests: Form handling, controlled components, validation

Build a contact form that collects user information and submits it to an API. Sounds simple, right? But this question reveals a lot about how you handle form state, validation, and user feedback.

What interviewers look for:

• Controlled vs uncontrolled components
• Form validation patterns
• Error handling and user feedback
• Clean state management

Practice tip: Focus on making the form accessible and user-friendly. Think about error messages, loading states, and success feedback.

→ Practice this question on GreatFrontEnd

2. Progress bar

What it tests: Dynamic styling, props handling, visual feedback

Create a progress bar that shows completion percentage. This question tests your ability to work with dynamic styles and create visual feedback for users.

What interviewers look for:

• How you handle dynamic styling
• Props validation and default values
• Clean, reusable component design
• Smooth visual transitions

Practice tip: Think about edge cases , what happens with invalid percentages? How do you make it look smooth?

→ Practice this question on GreatFrontEnd

3. Temperature converter

What it tests: Two-way data binding, calculations, controlled inputs

Build a widget that converts between Celsius and Fahrenheit. This seems basic, but it’s a great test of how you handle two-way data flow.

What interviewers look for:

• Bidirectional data updates
• Input handling and validation
• Mathematical accuracy
• User experience considerations

Practice tip: Make sure both inputs stay in sync when one changes. Handle decimal places gracefully.

→ Practice this question on GreatFrontEnd

4. Accordion

What it tests: Conditional rendering, state management, user interaction

Create an accordion component with collapsible sections. This tests your understanding of conditional rendering and managing multiple component states.

What interviewers look for:

• Clean state management for multiple sections
• Smooth expand/collapse behavior
• Proper event handling
• Reusable component structure

Practice tip: Consider whether multiple sections can be open at once, and how to handle default states.

→ Practice this question on GreatFrontEnd

Intermediate Level Questions

5. Todo list

What it tests: List manipulation, CRUD operations, local state management

Build a todo list where users can add, delete, and mark tasks as complete. This is a classic that tests your ability to manage arrays and handle multiple operations.

What interviewers look for:

• Efficient list updates
• Proper key handling for list items
• State immutability
• User experience polish

Practice tip: Pay attention to how you update the array state. Avoid common pitfalls like mutating state directly.

→ Practice this question on GreatFrontEnd

6. Star rating

What it tests: Interactive components, visual feedback, event handling

Create a star rating component where users can click to set a rating. This tests your ability to create intuitive user interactions.

What interviewers look for:

• Hover effects and visual feedback
• Click handling and state updates
• Clean component API design
• Accessibility considerations

Practice tip: Think about the user experience , hover states, visual feedback, and making it obvious how to interact.

→ Practice this question on GreatFrontEnd

7. Modal dialog

What it tests: Portal usage, focus management, event handling, accessibility

Build a modal that can be opened and closed. This question goes deeper into React patterns and accessibility.

What interviewers look for:

• Proper modal implementation (portals)
• Focus management and accessibility
• Backdrop click handling
• Clean open/close logic

Practice tip: Focus on accessibility , keyboard navigation, focus trapping, and screen reader support.

→ Practice this question on GreatFrontEnd

8. Tabs component

What it tests: Component composition, state management, navigation patterns

Create a tabs interface that shows different content panels. This tests your understanding of component composition and navigation patterns.

What interviewers look for:

• Clean tab switching logic
• Proper content organization
• Reusable component design
• Keyboard navigation support

Practice tip: Think about how to make the API flexible , can tabs be added dynamically? How do you handle tab labels and content?

→ Practice this question on GreatFrontEnd

Advanced level questions

9. Image carousel

What it tests: Complex state management, performance optimization, user interactions

Build an image carousel with navigation controls. This tests your ability to handle more complex user interactions and performance considerations.

What interviewers look for:

• Smooth transitions between images
• Navigation control implementation
• Performance with large image sets
• Touch/swipe support considerations

Practice tip: Focus on the user experience , smooth transitions, proper loading states, and intuitive controls.

→ Practice this question on GreatFrontEnd

10. Data table with pagination

What it tests: Performance optimization, complex state management, user experience

Create a data table that can handle large datasets with pagination. This is where things get interesting , you need to think about performance and user experience.

What interviewers look for:

• Efficient data handling
• Pagination logic and state management
• Table performance with large datasets
• User experience considerations

Practice tip: Think about loading states, error handling, and how to make pagination intuitive for users.

→ Practice this question on GreatFrontEnd

How to practice effectively

Here’s my advice for getting the most out of these questions:

Start with the basics: Even if you’re experienced, work through the beginner questions first. They’ll help you establish good patterns and remind you of fundamentals.

Focus on user experience: Don’t just make it work, make it feel good to use. Think about loading states, error handling, and accessibility.

Practice explaining your approach: In real interviews, you’ll need to talk through your thinking. Practice explaining why you chose certain patterns or approaches.

Time yourself: Give yourself realistic time constraints. Most interview coding sessions are 45–60 minutes.

Review solutions: After attempting each question, study different approaches. There’s usually more than one way to solve these problems.

What’s next?

These 10 questions will give you a solid foundation for React interviews. But if you want to go deeper, I recommend checking out our complete collection of 50 React coding questions on GreatFrontEnd. Each question includes:

• Interactive coding environment
• Comprehensive test cases
• Expert solutions and explanations
• Difficulty progression from beginner to advanced

You can also explore our React Interview Playbook, which covers everything from common React concepts to advanced patterns that senior developers need to know.

Remember, the goal isn’t just to memorize solutions, it’s to understand the patterns and thinking behind them. When you can confidently approach any React component challenge, you’ll know you’re ready for your interviews.

Building React apps with custom designs can be tricky. You want components that work perfectly but don’t force you into a specific look. That’s where headless UI libraries come in.

These libraries give you all the functionality & accessibility, keyboard navigation, focus management, without any styling. You get the behavior, you control the appearance.

But with so many options out there, which one should you pick for your project?

What makes headless UI libraries special

Think of headless UI libraries as the engine of a car. They handle all the complex stuff under the hood while letting you design the exterior however you want.

Regular component libraries like Material-UI or Bootstrap come with predefined styles. They look great out of the box, but customizing them can be a pain. Headless libraries flip this approach, they give you rock-solid functionality and let you handle the styling completely.

The top players in 2025

Let me walk you through the libraries that are making waves this year.

Radix UI

The comprehensive choice

Radix UI is like the Swiss Army knife of headless libraries. With 32 components, it covers almost everything you’ll need for a modern web app.

What makes it great:

• Zero configuration needed
• Works perfectly with Tailwind CSS
• Amazing TypeScript support
• Used by big companies like Linear and Modulz

Best for: Teams who want a complete solution and don’t mind a slightly larger bundle size.

The numbers: 13.5k GitHub stars, 1.3M weekly downloads

Headless UI

The tailwind team’s pick

Created by the same team behind Tailwind CSS, Headless UI focuses on doing fewer things exceptionally well.

What makes it great:

• Perfect integration with Tailwind
• Rock-solid accessibility
• Clean, simple API
• Excellent documentation

Best for: Projects already using Tailwind CSS or teams who prefer a minimalist approach.

The numbers: 23.6k GitHub stars, 1.3M weekly downloads

React aria

The accessibility champion

Adobe’s React Aria takes accessibility seriously. Really seriously. If you need to meet strict accessibility requirements, this is your go-to.

What makes it great:

• Built-in internationalization
• Adaptive interactions (works on mobile and desktop)
• Screen reader optimization
• Comprehensive accessibility features

Best for: Enterprise applications or any project where accessibility compliance is critical.

The numbers: 11.1k GitHub stars, 116k weekly downloads

Aria kit

The modern alternative

Aria Kit brings fresh ideas to the headless UI space with a focus on modern React patterns and excellent developer experience.

What makes it great:

• Uses modern React patterns
• Great TypeScript support
• Excellent state management
• Clean component composition

Best for: Teams who want modern React patterns and don’t mind working with a newer library.

The numbers: 7.5k GitHub stars, 53k weekly downloads

Ark UI

The framework agnostic

While we’re focusing on React, Ark UI deserves a mention because it works across multiple frameworks, React, Vue, and Solid.

What makes it great:

• Consistent API across frameworks
• State machines for predictable behavior
• Great for design systems
• Scalable architecture

Best for: Teams working with multiple frameworks or planning to expand beyond React.

The numbers: 2.8k GitHub stars, 29k weekly downloads

How to pick the right one

Choosing a headless UI library isn’t just about features, it’s about what fits your project and team.

Consider your styling approach

Using tailwind CSS? → Headless UI is your best bet. It’s made by the same team and the integration is seamless.

Building a custom design system? → Radix UI gives you the most components to work with.

Need maximum accessibility? → React Aria has the most comprehensive accessibility features.

Think about your team

New to headless UI? → Start with Headless UI. It has the gentlest learning curve.

Want cutting edge React patterns? → Aria Kit embraces modern React development.

Working with designers who know CSS-in-JS? → Radix UI plays nicely with styled-components and emotion.

Project requirements matter

Building for enterprise? → React Aria’s accessibility and internationalization features are hard to beat.

Creating a quick prototype? → Headless UI gets you up and running fast.

Planning a long-term design system? → Radix UI’s comprehensive component set will grow with you.

Quick comparison

My take

If you’re just starting with headless UI libraries, go with Headless UI. It’s simple, well-documented, and works great with Tailwind.

For larger projects where you need more components, Radix UI is fantastic. The API is consistent, and you’ll find components for almost every use case.

If accessibility is non-negotiable, like for government or enterprise apps, React aria is worth the extra complexity.

Want to practice?

Theory is great, but nothing beats hands-on experience. If you want to see these libraries in action with real examples and practice implementing them yourself, check out our complete guide to headless UI libraries.

We’ve got detailed code examples, implementation tips, and practice exercises to help you master whichever library you choose.

What’s your experience?

Have you worked with any of these libraries? Which one worked best for your project? I’d love to hear about your experience in the comments below.

And if you’re preparing for front end interviews, headless UI libraries are definitely something worth knowing about. Many companies are moving toward this approach, and being familiar with the concepts will definitely help in your next interview.

Originally published on GreatFrontEnd, where front end developers level up their skills.

Ever wondered how news websites show breaking news instantly, or how your favorite chat app gets new messages without you refreshing the page? The magic behind this real-time communication is often Server-Sent Events (SSE).

If you’re a front end developer preparing for interviews or just curious about how modern web apps work, SSE is definitely worth understanding. Let’s break it down in simple terms.

What are server-sent events?

Think of Server-Sent Events like a one-way radio broadcast. Your web page tunes into a server’s “radio station” and receives updates whenever the server has something new to share. Unlike regular web requests where you ask for information and get a response, SSE keeps the connection open so the server can send you updates anytime.

The best part? It’s built right into modern browsers, so you don’t need any fancy libraries to get started.

SSE vs WebSockets: Which one to pick?

When people talk about real-time web communication, WebSockets usually come up too. Here’s a quick comparison to help you understand when to use what:

Use SSE when: You need live updates but don’t need to send data back to the server frequently (news feeds, stock prices, notifications).

Use WebSockets when: You need real-time chat, gaming, or collaborative editing where both sides need to communicate actively.

Getting started with SSE

The beauty of Server-Sent Events lies in their simplicity. Here’s how you can start receiving real-time updates in just a few lines of JavaScript:

javascript
// Connect to the server's event stream
const eventSource = new EventSource('/live-updates');

// Listen for messages
eventSource.onmessage = function(event) {
    console.log('New update:', event.data);
    // Update your UI here
};

// Handle connection events
eventSource.onopen = function() {
    console.log('Connected to live updates');
};

eventSource.onerror = function() {
    console.log('Connection error - will retry automatically');
};

That’s it! Your webpage is now listening for real-time updates. The browser handles reconnections automatically if the connection drops, which is pretty neat.

Real-world applications

SSE shines in several scenarios:

Live sports scores: Sports websites use SSE to update scores in real-time without users hitting refresh constantly.

Stock price updates: Financial platforms stream live price changes to keep traders informed instantly.

System monitoring: Dashboards showing server health, user activity, or application metrics benefit from continuous data streams.

News feeds: Breaking news alerts and live blog updates reach readers immediately.

Progress tracking: File uploads, data processing, or any long-running task can send progress updates to keep users informed.

Why developers love SSE

Simple implementation: No complex protocols or libraries needed. If you know basic JavaScript, you’re good to go.

Automatic reconnection: The browser handles connection drops and retries for you. Less code to maintain.

Built-in browser support: Works across all modern browsers without polyfills.

Lightweight: Less overhead compared to WebSockets for one-way communication.

Standard HTTP: Works with existing infrastructure, load balancers, and CDNs without special configuration.

Things to keep in mind

While SSE is fantastic, there are a few limitations worth knowing:

Text only: You can only send text data, so binary files need to be encoded (which adds overhead).

One direction: If you need to send data back to the server frequently, WebSockets might be better.

Connection limits: Browsers limit concurrent SSE connections per domain (usually around 6), though HTTP/2 helps with this.

Mobile considerations: On mobile networks, connections might drop more frequently, but the automatic reconnection handles this gracefully.

Getting interview-ready

Server-Sent Events frequently come up in front end interviews because they demonstrate understanding of:

• Real-time communication patterns
• Browser APIs
• Performance considerations
• When to choose different technologies

Interviewers love asking about the trade-offs between SSE and WebSockets, so make sure you understand both technologies and their use cases.

Ready to practice?

Understanding SSE conceptually is great, but nothing beats hands-on practice. If you want to dive deeper with comprehensive examples, practice questions, and real interview scenarios, check out our complete Server-Sent Events guide on GreatFrontEnd.

You’ll find detailed code examples for both client and server implementations, plus practice questions that help you master SSE for your next interview.

Server-Sent Events might seem like a small piece of the web development puzzle, but they’re incredibly powerful for creating engaging, real-time user experiences. Start with simple implementations and gradually build more complex applications as you get comfortable with the technology.

You’re debugging your JavaScript code at 2 AM, and something weird is happening. A function is somehow accessing a variable that should have been destroyed ages ago. Welcome to the world of closures, one of JavaScript’s most powerful features that can either save your day or drive you completely insane.

I’ve been there. Early in my career, closures felt like black magic. But once I understood them, they became one of my favorite tools for writing clean, efficient code. Let me break them down in a way that actually makes sense.

What’s a closure, actually?

Here’s the deal: a closure happens when a function “remembers” variables from the place where it was created, even after that place is long gone.

Think of it like this, imagine you’re moving out of your apartment, but you pack a suitcase with your favorite things. Even in your new place, you still have access to everything in that suitcase. That’s exactly what closures do with variables.

javascript
function createPersonalGreeting(name) {
  // This variable lives here
  const personalMessage = `Hey there, ${name}!`;
  
  // This function "packs" personalMessage in its suitcase
  return function() {
    console.log(personalMessage);
  };
}

const greetJohn = createPersonalGreeting("John");
greetJohn(); // "Hey there, John!"

Even though createPersonalGreeting finished running, the returned function still remembers personalMessage. That’s closure in action.

Why should you care?

Closures aren’t just a fancy concept to impress people at meetups. They solve real problems every day.

Problem 1: Creating private variables

JavaScript doesn’t have true private variables, but closures give us the next best thing:

javascript
function createBankAccount(initialBalance) {
  let balance = initialBalance;
  
  return {
    deposit: function(amount) {
      balance += amount;
      return balance;
    },
    withdraw: function(amount) {
      if (amount <= balance) {
        balance -= amount;
        return balance;
      }
      return "Insufficient funds";
    },
    getBalance: function() {
      return balance;
    }
  };
}

const myAccount = createBankAccount(100);
console.log(myAccount.getBalance()); // 100
myAccount.deposit(50);
console.log(myAccount.getBalance()); // 150

// You can't directly access or modify balance from outside
console.log(myAccount.balance); // undefined

The balance variable is completely protected. The only way to interact with it is through the methods we provide. Pretty neat, right?

Problem 2: Event handlers that remember context

This one trips up a lot of developers:

javascript
function setupButtons() {
  const buttons = document.querySelectorAll('.action-btn');
  
  for (let i = 0; i < buttons.length; i++) {
    buttons[i].addEventListener('click', function() {
      console.log(`Button ${i + 1} was clicked`);
    });
  }
}

Each click handler remembers its own value of i. Without closures, they’d all show the same number (spoiler: it would be the last value of i).

The classic gotcha (and how to fix it)

Here’s where most developers get confused. Check out this code:

javascript
// This doesn't work like you'd expect
function createCounters() {
  const counters = [];
  
  for (var i = 0; i < 3; i++) {
    counters.push(function() {
      console.log(i);
    });
  }
  
  return counters;
}

const myCounters = createCounters();
myCounters[0](); // 3 (not 0!)
myCounters[1](); // 3 (not 1!)
myCounters[2](); // 3 (not 2!)
What happened? All the functions share the same i variable, and by the time any of them run, the loop is done and i equals 3.
The fix? Create a new scope for each iteration:
javascript
function createCounters() {
  const counters = [];
  
  for (let i = 0; i < 3; i++) { // Using 'let' instead of 'var'
    counters.push(function() {
      console.log(i);
    });
  }
  
  return counters;
}

const myCounters = createCounters();
myCounters[0](); // 0
myCounters[1](); // 1
myCounters[2](); // 2

Using let creates a new binding for each iteration. Problem solved.

Real-world example: A simple timer

Here’s something you might actually use in a project:

javascript
function createTimer(startTime = 0) {
  let currentTime = startTime;
  let isRunning = false;
  let intervalId = null;
  
  return {
    start: function() {
      if (!isRunning) {
        isRunning = true;
        intervalId = setInterval(function() {
          currentTime++;
          console.log(`Time: ${currentTime}s`);
        }, 1000);
      }
    },
    
    stop: function() {
      if (isRunning) {
        isRunning = false;
        clearInterval(intervalId);
      }
    },
    
    reset: function() {
      currentTime = startTime;
      this.stop();
    },
    
    getTime: function() {
      return currentTime;
    }
  };
}

const myTimer = createTimer(10);
myTimer.start(); // Starts counting from 10
// Later...
myTimer.stop();
console.log(myTimer.getTime()); // Shows current time

Each timer instance has its own private state. You can create multiple timers, and they won’t interfere with each other.

When closures can bite you

Closures aren’t always your friend. They can cause memory leaks if you’re not careful:

javascript
function attachListeners() {
  const hugeArray = new Array(1000000).fill('data');
  
  document.getElementById('button').addEventListener('click', function() {
    // This function keeps hugeArray alive in memory
    // even though we only need one small piece
    console.log('Button clicked');
  });
}

The event handler creates a closure that holds onto hugeArray, preventing garbage collection. In cases like this, be mindful of what variables your closures are capturing.

The bottom line

Closures are everywhere in JavaScript. Every time you use callbacks, event handlers, or any function that references variables from its outer scope, you’re using closures.

They’re not magic, they’re just functions with good memory. Once you get comfortable with them, you’ll start seeing elegant solutions to problems that used to require ugly workarounds.

The key is practice. Start simple, experiment with the examples above, and gradually work your way up to more complex scenarios.

Want to test your understanding? Try building a closure-based solution the next time you need private variables or persistent state in your code. And if you’re preparing for interviews, closures are definitely worth mastering, they come up constantly in technical discussions.

Ready to dive deeper into JavaScript concepts like closures? Check out our collection of JavaScript questions where you can practice with real coding challenges and get instant feedback. Perfect for sharpening your skills and building confidence for your next technical interview.

Picture this: You’re building a search feature and every keystroke triggers an API call. Or your scroll event handler is firing hundreds of times per second, making your app crawl. These aren’t just minor annoyances, they’re performance killers that can frustrate users and crash browsers.

The good news? Two simple techniques can solve most of these problems: debouncing and throttling. But here’s where many developers get stuck, when do you use which one?

The elevator button problem

Think about pressing an elevator button. With debouncing, it’s like the elevator waits until you’ve completely stopped pressing buttons before deciding which floor to go to. With throttling, it’s like the elevator only listens to button presses once every few seconds, no matter how frantically you press.

Debouncing delays action until things calm down. Throttling limits how often actions can happen.

Real scenarios where you need debouncing

Search autocomplete

You don’t want to hit your search API for every single letter someone types. Instead, wait until they pause typing:

javascript
// Wait 300ms after user stops typing
const debouncedSearch = debounce(searchAPI, 300);

Form validation

Don’t show error messages while someone is still typing their email. Give them a chance to finish first.

Button click protection

Prevent accidental double-clicks that could submit a form twice or charge a credit card multiple times.

Auto-save features

In text editors, you want to save work, but not on every single character change. Wait for natural pauses.

Real scenarios where you need throttling

Scroll events

Scroll events can fire 60+ times per second. You don’t need to update your “scroll to top” button position that frequently:

javascript
// Update at most once every 100ms
const throttledScroll = throttle(updateScrollPosition, 100);

Window resize

When users resize their browser window, you might need to recalculate layouts, but not 50 times per second.

Mouse movement tracking

If you’re building a drawing app or tracking mouse coordinates, throttling prevents overwhelming your system.

API rate limiting

Some APIs only allow a certain number of calls per minute. Throttling helps you stay within those limits.

The quick decision guide

Use debouncing when:

• You want to wait until activity stops
• The last action is what matters most
• Examples: search, form validation, auto-save

Use throttling when:

• You want regular, consistent updates
• You need to maintain responsiveness during continuous activity
• Examples: scroll events, resize events, mouse tracking

Common mistakes to avoid

Don’t debounce everything. I’ve seen developers debounce button clicks with long delays, making their app feel sluggish. Users expect immediate feedback from buttons.

Don’t throttle user input. Throttling keystrokes or form inputs creates a terrible user experience. People notice when their typing feels delayed.

Pick the right timing. A 300ms debounce works well for search, but it’s too slow for auto-save. A 100ms throttle is good for scroll events, but too aggressive for API calls.

Testing your implementation

Here’s a simple way to test if you’ve chosen correctly:

• For debouncing: Rapidly trigger the event, then stop. The function should only execute once after you stop.
• For throttling: Continuously trigger the event. The function should execute at regular intervals, not constantly.

The bottom line

Debouncing and throttling aren’t just performance optimizations , they’re essential tools for building responsive, user-friendly applications. The key is understanding your specific use case and choosing the right technique.

Remember: debounce when you want to wait for calm, throttle when you want to limit frequency during activity.

Want to practice implementing these concepts with real examples and see how they perform in different scenarios? Check out our comprehensive interactive guide where you can experiment with code and test your understanding with hands-on exercises.

Last month, I was helping a friend review resumes for a front end position at his startup. Out of 150 applications, we rejected 80% within the first 30 seconds.

Not because these developers lacked skills. But because their resumes made basic mistakes that screamed “I don’t understand what front end development is about.”

Here are the five biggest mistakes I see front end developers make on their resumes, and how to fix them fast.

Mistake #1: Using Generic Job Titles

What I see: “Software Engineer at XYZ Company”

Why it’s killing you: When a recruiter searches for “front end developer” in their system, your resume doesn’t show up. You’re invisible.

The fix: Be specific about what you actually do.

Instead of: “Software Engineer” Use: “Front End Engineer” or “Front End Software Engineer”

If your official title is generic but you’ve been doing front end work, use what reflects your actual role. Nobody’s going to call HR to verify your exact title. They care about what you can do.

Pro tip: Sprinkle “front end” throughout your resume. ATS systems love keyword matches.

Mistake #2: Ugly, Hard-to-Read Formatting

Here’s the thing, you’re applying to build user interfaces. If your resume looks like it was designed in 1995, what does that say about your design sense?

What kills resumes:

• Fancy fonts that don’t load properly
• Multiple columns that confuse ATS systems
• Tiny text that requires a magnifying glass
• Colors that don’t print well

The fix:

• Single column layout
• Common fonts (Arial, Calibri, nothing fancy)
• 11pt font minimum
• Clean, simple design

Your resume doesn’t need to look like a Dribbble shot. It just needs to look professional and be easy to read.

Mistake #3: Boring Project Descriptions

What I see: “Built a website using React, CSS, and JavaScript”

What I think: “So did every bootcamp graduate last week.”

What you should write instead:

“Built a performant e-commerce site handling 500+ daily transactions. Reduced page load time by 40% using code splitting and lazy loading. Technologies: Next.js, React, Stripe API, CSS modules. 15k monthly active users.”

See the difference? The second one tells me:

• Scale (500+ transactions, 15k users)
• Impact (40% faster load time)
• Technical decisions (code splitting, lazy loading)
• Business value (e-commerce, transactions)

Quick formula: What you built + Scale + Impact + Technologies used

Mistake #4: Listing Every JavaScript Library Ever Created

I once saw a resume that listed 47 different technologies. Forty-seven.

Here’s what happens: Instead of looking impressive, you look like you don’t know what actually matters.

The fix: Be strategic about what you include.

Include technologies that:

• Appear in the job listing
• Influence architecture (React, Angular, Vue)
• Show you’re current (TypeScript, Tailwind CSS)
• Demonstrate depth (if you know Redux, you understand state management)

Don’t include:

• Every utility library (Lodash, Moment.js)
• Basic tools everyone uses (npm, Chrome DevTools)
• Technologies you touched once in a tutorial

Example skills section: Languages: HTML, CSS, JavaScript, TypeScript Technologies: React, Next.js, Tailwind CSS, Jest, Cypress, GraphQL

Clean. Focused. Shows modern stack knowledge.

Mistake #5: No Personal Projects (or Terrible Ones)

“But I have work experience!”

Great. But front end moves fast. React 18 features, CSS Grid, modern deployment tools — if you’re not building side projects, how do I know you keep up?

What makes a good project:

• Solves a real problem (not another todo app)
• Uses modern technologies
• Has a live demo I can click
• Code is on GitHub with a good README
• Shows your thought process

Red flags:

• Projects from 2019 using jQuery
• Broken demo links
• No code available
• Generic tutorials you followed

Quick project ideas that impress:

• A tool that solves a problem you have
• An app that uses a modern API
• Something that shows performance optimization
• A component library or design system

The Bottom Line

Your resume has one job: get you an interview.

These five fixes won’t guarantee you’ll get hired. But they’ll get you past that first 30-second screening where most resumes die.

Front end development is competitive. Your resume needs to show you understand both the technical and visual sides of the job.

Want the complete guide? I’ve put together a comprehensive front end resume playbook with examples, templates, and detailed breakdowns of what works. Check it out here.