Open-source project
felipefialho/frontend-challenges avatar
felipefialho/frontend-challenges

frontend-challenges is one markdown table, and the stack column dates it

A public list of open-source challenges from companies around the world

15,045 stars1,261 forksUnknownMIT

At a glance

What is it?
This repository is a public list of take-home coding challenges that companies have open-sourced, with the required stack spelled out per entry. The useful reading is not the links but the stacks: Redux, Sass, Webpack and Bower show what was being asked for when each challenge was written.
Who is it for?
Use this repository as a source of real, self-contained front-end exercises when you want to practise on something other than a tutorial, and read the stack column before choosing, because the requirements reflect when each challenge was written rather than current practice. Do not use it as evidence of what companies ask for today, since entries carry Redux, Bower, task runners and a NodeJS plus PHP pairing that no longer describe a typical front-end role.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 13 days ago.
What is it written in?
GitHub does not report a main language for this repository.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

From daily snapshots

Star history

  • felipefialho/frontend-challenges15,045 ★ · +6
Star history
Repository2026-10-162026-10-23
felipefialho/frontend-challenges15k15k

6 Stars in the last 7 days, measured from the daily GitHub snapshot. Compare with other projects

Editorial analysis

Three files in the repository, one table in the README

The top-level contents of this repository are `.github/`, `license` and `readme.md`. That is the entire project. There is no generator script, no data file, no CI that validates entries and no per-entry directory.

Everything lives in the README as a single markdown table with five columns. The first is a language marker, either `pt` or `en`. The second is the company, sometimes with a hyphen and a number when a company published more than one challenge, as Addison Global and AirCall both did. The third is the required stack. The fourth is a link to the challenge repository. The fifth is a link to that company's LinkedIn jobs page.

That design has a consequence worth stating plainly. Every entry is a hand-maintained markdown row, so the list's accuracy depends entirely on the maintainer noticing that a challenge repository was deleted, renamed, or changed its instructions. There is nothing that would catch that automatically, and no release history to consult.

The stated purpose is to test knowledge using real job challenges, and the README asks that they be playful and open-source, with a warning marker attached to that requirement. Licence is MIT.

The stack column is the part worth reading

If you only look at one column, look at the third. It records what each company asked a candidate to know, and The column records the stack listed for each challenge.

The dominant ask is React, usually paired with Redux. Amaro is listed as React, Redux, Sass and Webpack. Chaordic as HTML, SASS, React, Redux. Beleza Na Web as React with CSS in JS. That cluster is unmistakably one era: a component library plus a predictable state container plus a CSS preprocessor plus a bundler, specified as four separate skills.

A second cluster asks for the platform only, listed as HTML, CSS and JS, and companies such as 1STi, Apiki, Ciclic, Concrete Solutions, Creditas and Buscapé fall into that group. A third is vaguer still, listed as Framework JS, Preprocessor CSS and Task Runners, which is how B2W, Contabilizei and Cubo Network describe the requirement. A stack described that loosely is asking candidates to demonstrate their own tool choices rather than match a fixed one.

The fourth column is where the date comes from. Redux, Sass and task runners are named requirements in some entries.

That does not make the challenges worthless. It makes them exercises in a specific technology context, which for practising is a feature rather than a defect.

One entry is not a front-end challenge at all

Clima Tempo is listed with NodeJS and PHP as its stack, linking to a repository called `challenge-accepted`. No HTML, CSS or browser technology appears in its requirements.

That single row is informative about how the list was assembled. The README describes itself as a list of front-end challenges, and this entry does not match that description on its face. NodeJS and PHP appear in its listed stack.

Either way, it is a reminder that the list is curated by a person making a judgement call per row, and the judgement is not always visible from the table. There is no note field explaining why an entry was included.

A second naming pattern in the table is worth noticing. Several challenges are named after the company's process rather than the product: `recrutamento-fe` at Concrete Solutions, `front-end-teste` at Contabilizei, `test-frontend` at Ciclic, `exercicios` at Buscapé. These are internal Portuguese-language recruiting repositories, and the language marker column records that as `pt`. So the list spans two audiences, and a reader filtering by language is filtering by the language of the challenge instructions, not the country of the company.

The LinkedIn column is a search shortcut, not a data point

The fifth column links to each company's LinkedIn jobs page, and it is worth being clear that this is navigation rather than metadata.

It is also inconsistent in a way that limits how much you can read into it. Some rows fill it, some leave it as a dash. Addison Global, AirCall, Amaro's later row and Chaordic all show a dash, while 1STi, Amaro, Apiki, B2W, Barato Coletivo, Beleza Na Web, Buscapé, Clima Tempo, Concrete Solutions, Contabilizei, Creditas and Cubo Network all have links.

A dash does not mean the company has no openings, and a link does not mean the challenge is current. The column just records whether the maintainer filled it in. Reading it as evidence about hiring volume would be a mistake.

There is also a naming wrinkle in the links themselves. Buscapé's jobs link points at a company slug for Zoom Buscapé rather than the Buscapé name, which is the kind of detail you only notice when you follow the links. It suggests the column was filled in by searching LinkedIn rather than copied from the challenge repository, which is normal and harmless, but it does mean the column is the least reliable part of the row.

The challenge link is the authoritative field. Everything else in the row is context.

Maintenance without a release history

The repository has no GitHub releases and its primary language is recorded as unknown, which is consistent with a repository containing no code. The whole content is documentation.

The last push was on 2026-10-09 and the repository is not archived, so the list is still being touched. There is no commit convention documented, no changelog and no versioning, which means the practical way to see what changed is to read the commit history on `main` directly.

That is not a criticism so much as a description of the maintenance model. A link directory has a different failure mode from a library: it does not break, it rots. Entries disappear when a company renames or archives a repository, and a stale link in a list like this is more likely than in a codebase because nobody depends on it in CI.

The `.github/` directory presumably holds templates, since the README does not describe issue templates or a pull request process for this repository and the topics list includes `companies-list`, `challenge`, `challenges`, `front-end`, `job-challenge`, `jobs` and `knowledge`. If you want to add an entry, the practical route is a pull request against the README, and whether that is the intended route is worth confirming in the `.github/` directory rather than assuming.

Where the list is the wrong tool

The first wrong case is using it to research what companies ask for in hiring interviews. The sample is not random and not current. The visible entries are concentrated in Brazilian companies and in stacks featuring React, Redux, Sass and Webpack. That is a distribution artefact, not a finding about employers.

The second wrong case is treating a challenge repository as a maintained exercise. Each entry points at a company-owned repository that follows that company's lifecycle. A company can delete it, rewrite the instructions, or replace the assignment entirely, and the table in this README will keep the link. Before you spend an evening on one, open it and read the current instructions.

The third is expecting a graded assessment. These are take-home exercises used as hiring filters, and a company that publishes one is publishing a prompt, not a course. There is no solution set here, no difficulty rating and no indication of how long anything should take.

What it is genuinely good for is narrow and real: a set of self-contained front-end builds with a stated stack, hosted on GitHub, free to work on. Compared with a tutorial that walks you through the answer, an unanswered brief with a fixed scope is closer to the work itself. That is the value, and it does not need the list to be current to be useful.

Editorial conclusion

Use this repository as a source of real, self-contained front-end exercises when you want to practise on something other than a tutorial, and read the stack column before choosing, because the requirements reflect when each challenge was written rather than current practice. Do not use it as evidence of what companies ask for today, since entries carry Redux, Bower, task runners and a NodeJS plus PHP pairing that no longer describe a typical front-end role. Before spending time on one, open the challenge repository itself and check that its instructions still match what the table claims, and note that the repository is three files long, which means an entry can go stale without anything in the list telling you.

Frequently asked questions

What is in the felipefialho/frontend-challenges repository?

The repository contains three entries at the top level: `.github/`, `license` and `readme.md`. All the content is a markdown table in the README with columns for a language marker, the company, the required stack, a link to the challenge code and a link to the company's LinkedIn jobs page.

Which front-end stacks do these company challenges ask for?

The visible entries cluster on React, usually with Redux, plus Sass, CSS in JS or Webpack, and a separate group asks only for HTML, CSS and JS. Others describe the requirement loosely as Framework JS, Preprocessor CSS and Task Runners. One entry, Clima Tempo, lists NodeJS and PHP instead of any browser technology.

Can I submit a company challenge to this list?

The repository is MIT licensed, is not archived, and had its last push on 2026-10-09, so it is still being maintained. The README does not describe a contribution process, so check the `.github/` directory for templates before opening a pull request against the README table.

Official sources

  1. felipefialho/frontend-challenges on GitHub
  2. Issues
  3. License: MIT
  4. README
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/felipefialho-frontend-challenges.svg)](https://hysenlabs.com/projects/felipefialho-frontend-challenges)

Star history chart for your README

markdown
[![Star history](https://hysenlabs.com/chart/felipefialho-frontend-challenges.svg)](https://hysenlabs.com/projects/felipefialho-frontend-challenges)

Was this useful?