Front-end developer interview questions: ten files and no answer key

Nine files under src/questions, and one category hosted elsewhere

Most of the list is plain markdown sitting under src/questions/: general-questions.md, html-questions.md, css-questions.md, javascript-questions.md, testing-questions.md, performance-questions.md, network-questions.md, coding-questions.md and fun-questions.md. You can read them, copy them, fork them. The tenth entry is different. Accessibility Questions is an external link to another project's site rather than a file in this repository, which means the one category that most front-end interviews treat as a requirement is the one you cannot vendor, pin to a commit or mirror for offline reading. A team that forks this list for an internal loop should source that category separately, otherwise the questions you skip by accident are the accessibility ones.

The README tells you not to work through the whole list

The repository description says the questions exist to interview potential candidates, test yourself or completely ignore, and the first instruction the README gives is not to use them all: it is by no means recommended to use every single question here on the same candidate, because that would take hours. Picking a few items from the list should help you vet the skills you require. Read that as a boundary on what the project is. There is no scoring sheet, no pass mark, no difficulty rating attached to any item, so a scorecard, a rubric or an automated screen built on top of this list is your own construction. The repository ships the prompts and nothing that grades them, and a candidate who answers every question adequately has still told you nothing about ranking.

No category is scoped to a level, so difficulty is yours to set

Not one of the ten categories is split by seniority. A first-day front-end developer and a ten-year one nominally draw from the same general-questions.md and the same javascript-questions.md, so any gap between them has to come from how deep you push in the follow-up or from questions you add yourself. The README leans the other way, noting that many of these questions are open-ended and could lead to interesting discussions that tell you more about the person's capabilities than a straight answer would. That is good advice for an interview and a poor one for a filter, because an open question measures whoever talks most fluently unless you write down in advance what a strong answer contains and what a weak one sounds like.

Eleventy builds the site, and the path prefix is hard-coded

Content lives in src/, the generator configuration in config/eleventy.config.js, and package.json carries exactly two site scripts. One builds, the other serves locally:

"build": "eleventy --config=config/eleventy.config.js --pathprefix='Front-end-Developer-Interview-Questions/'"
"start": "eleventy --config=config/eleventy.config.js --serve --port 9090 --quiet"

That path prefix is why the published site sits under h5bp.org/Front-end-Developer-Interview-Questions/ rather than at a domain root, and it is the first thing a fork has to change: serve the same content from your own domain without editing that string and every generated asset and internal link resolves against a path your host does not serve. The contributor table is data rather than prose, produced by copying .all-contributorsrc into ./src/_data/contributors.json, which is why regenerating it is a script and not a hand-edited table.

The dev server is pinned to port 9090 with quiet output

Port 9090 is written into the serve script, and nowhere else does it appear. package.json declares no environment variable for it, and the README gives no flag for changing it, so a second project already on 9090 produces a failure rather than a fallback to a free port. The same command passes --quiet, which removes the build chatter that would otherwise tell you a template failed to parse. For a repository of markdown files that is a smaller problem than it would be for an application, but anyone running two copies locally, or a copy beside another Eleventy site, meets it on the first attempt rather than the first hard one.

resolutions pins axios to 0.18.1, and nothing checks the questions

The dependency list dates the project. The generator is held to the 2.x line at @11ty/eleventy ^2.0.1, with @11ty/eleventy-plugin-syntaxhighlight ^5.0.0, markdown-it ^14.1.0 and markdown-it-anchor ^8.6.7, and clean-css, html-minifier and uglify-es handling minification. More pointed is the resolutions block, which forces axios to 0.18.1 even though axios appears nowhere in devDependencies, so the override is aimed at something arriving transitively and every fresh install takes that exact release whatever upstream resolved. A fork inherits it, and dropping it is a decision you make on a static site with no runtime of its own. Nothing else in the scripts guards content: there is no test, lint or format command, so a broken internal link or a question added twice is caught by whoever reads the pull request.

One maintainer, and contributing links that point at master

Upkeep rests on one named person. The README lists @roblarsen as the current maintainer, and the contributor table credits work under roles such as Documentation, Reviewed Pull Requests, Translation, Infrastructure, Answering Questions, Talks and Maintenance. The last push to the repository was on 2026-06-16 and it is not archived, so nothing is frozen. Two rough edges follow from that shape. A single reviewer is the queue for every content change, and the README's own Getting Involved links address blob/master/ paths for the contributing guide and the license while the default branch is main, so anyone following them verbatim depends on a master branch that the branch setting does not promise.

No answers, no rubric, and no version per question

What the project does not contain matters as much as what it does. There is no answer key, no model answers, no scoring rubric, and no version or date attached to any individual question, so nothing in the repository tells you whether a question still matches the API it asks about or whether two interviewers would accept the same response. The README sends readers to an about page on h5bp.org for the project's history, so even the reasoning behind a question lives outside the repository. Two consequences for anyone adopting it. Treat the list as a prompt sheet for a conversation rather than a filter, and write your own expected answers before the interview starts, because no second interviewer reading this repository will learn what a passing answer looked like.

Editorial conclusion

Use this list as a prompt sheet for a human conversation, picking a handful of questions per candidate and writing your own expected answers first, because the repository holds questions and nothing that scores them. Do not use it as a filter or as the whole interview, since the README says the full set would take hours and one category is hosted elsewhere where you cannot control it. Before you rely on it, check which questions still match the APIs you work with, since no question carries a version or a date, and confirm the branch the contributing links point at.

Frequently asked questions

Official sources

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