Front-end Developer Interview Questions: A Curated Question Bank, Not a Hiring Playbook

What This Repository Actually Solves

The problem is simple: many interviewers run out of good questions, and many candidates do not know what to expect. This repository gives a list of front-end questions, grouped by topic, that you can use to interview candidates, test yourself, or ignore entirely. The README is explicit about the intended use, it is not a script to follow verbatim. It says using every question on one candidate would take hours, so you should pick a few. The audience is technical interviewers and front-end developers who want to gauge their own knowledge. It is not a tool that scores answers or predicts job performance. It is a curated index of prompts.

The Structure: Ten Files, One External Link

The README lists ten entries: nine Markdown files under src/questions/ and one external link. There are general questions, HTML, CSS, JavaScript, testing, performance, network, coding, and fun questions. Accessibility questions are not in the repository at all. The README points to an external page by Scott O'Hara. That is a notable design choice. Keeping accessibility separate means the main repo stays focused, but it also means the core list is incomplete if you want a single source. The table of contents lists the question files and the external accessibility link, and nothing about answers or scoring.

How to Get It Running: Clone and Read

The questions are a collection of Markdown files, and reading them needs no build step. To use it, you clone it with git clone https://github.com/h5bp/Front-end-Developer-Interview-Questions.git, then open the files in any text editor or browser. The README lists the table of contents with relative links, so you can navigate from one file to another. A package.json does exist, but only for the Eleventy site build (the `build` and `start` scripts) and the contributor scripts. The primary language listed is Nunjucks, but that likely refers to the site template on the homepage, not the question files. The actual content is plain Markdown. This simplicity is a strength, it works anywhere, but it also means there is no versioning of the content beyond git history. You are reading raw text.

The Open-Ended Design and Its Trade-Off

The README states that many questions are open-ended and could lead to discussions that reveal more than a straight answer. That is the core philosophy. Open-ended questions like 'Explain how a browser renders a page' force the candidate to structure their own response, which can show depth or expose gaps. The trade-off is that the repository gives no guidance on what a good answer looks like. A junior interviewer may not know when an answer is sufficient. The project does not claim to solve that, but it is a real limitation for any team that wants consistent hiring.

Maintenance and Upgrade Cost

The repository is under the H5BP organization, which is a known name in front-end tooling. It is currently maintained by @roblarsen, according to the README. The last push was on 2026-06-16 and the repository has no GitHub releases, which suggests the project is in a stable, low-activity state. That is not necessarily a problem, interview questions do not change as fast as frameworks. But it does mean you should check the last commit date yourself before relying on it. The content may lag behind new web platform features. The license is MIT, which is permissive. You can fork it, modify it, and use it internally without restriction. The main cost is not technical, it is the time you spend curating questions that fit your specific roles. The repository is a starting point, not a finished hiring kit.

The Wrong Tool for Structured Hiring

If your process requires every candidate to answer the same set of questions with a scoring rubric, this repository is the wrong tool. It offers no answer keys, no weightings, no pass/fail criteria. It is also not a live coding platform. The coding questions are listed as prompts, but you would have to set up your own environment to test them. For a large company with standardized interviews, you would need to build a separate system to track responses and grades. The repository also has no localization beyond community translations, which are not listed in the README's table of contents. You are getting an English-centric list. If you hire in other languages, you would need to translate or adapt the questions yourself.

A Real Alternative: The Accessibility Questions Repository

The README links to scottaohara.github.io/accessibility_interview_questions as the accessibility section. That is a separate project with its own structure and maintenance. The difference in approach is clear: instead of bundling accessibility into a single list, the H5BP project defers to a specialist resource. It means you have to check two places when preparing for an interview. Other alternatives exist, such as interview question collections on GitHub that include answer guides or difficulty ratings, but the README does not mention them. The key contrast is that this repository is deliberately minimal, while a more complete solution would integrate answers, scoring, and role-based filters. If you want that, you would need to build it yourself.

Editorial conclusion

Adopt this repository if you are an interviewer who wants a broad, community-maintained starting point for open-ended questions, or a developer who wants to self-test across the major front-end domains. Skip it if you need a structured scoring system, answer keys, or a tool that adapts to seniority levels. Before using it, verify the current state of each linked file, especially the external accessibility questions, and confirm that the questions match the roles you hire for. The repository is a static list, not a testing framework, so treat it as a source of prompts, not a complete hiring process.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository