14 gotchas around coding challenges for Frontend Engineers

I do not write this article to make it easier for candidates to pass our coding challenges and I will not go into detail on them. I will share my personal point of view which might not reflect other reviewers perspective. Some parts that I mention are most probably also applicable to backend engineers but I am focusing on frontend engineering as this is my domain.

Photo by athree23 on pixabay


The reviewer

// TODO: add debounce logic to search input
// TODO: move to service worker for increased performance
// TODO: add test case also for condition ABC
// TODO: move into context to enable cross component access to state
// TODO: split into sub components
// TODO: move logic into shared utils function file

Clean code patterns

Another advantage of following the upper points is that the candidate can explain the handed in solution in the technical interview better as navigating and orientating is way easier for herself/himself.

Syntax & coding style


Once I had a candidate who was using a Redux store to handle data in a shared state. The candidate tested the redux store and its reducers by initialising the store with mock data and dispatching actions to invoke the reducer functions. However the candidate only tested that these reducers were called and did not fail but did not test what the reducers actually should do.


Keep in mind that the coding challenge is an entrance card for the next phase in the hiring process. Which means that even if you follow all my mentioned points it is just one factor in a variety of other factors for a successful hire.

While a good coding challenge does not guarantee you to be hired a bad one results in a higher chance of being rejected.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store