Item — HN Reader

Thank you for the idea. We do know some parts of code where we have issues which might be good candidate for the interview.

Apart from this, do you have recommendations or ideas for the take home tests for frontend engineer interviews? In a previous hiring run, the test we used turned out to be too easy because all candidates were able to implement it successfully and offloaded work heavily to third-party libraries.

2 comments

FWIW, we ditched our take home tests a few years ago because candidates considered the ~8 hours required to complete it to be a waste of their time when they didn't have to go through that hassle for other comparable offers. It was a neat little project but about half of the candidates either rejected the notion of doing that test or simply didn't send in the result, so we used to lose about 50%.

Instead, we spend more time discussing real-world-oriented stuff, like what the parent is describing.

Personally, I like to orient the discussion toward failures and recoveries if the candidate doesn't do it on their own. You learn so much about someone that way.

I wouldn't give or do a take-home test, I respect people's time too much. Again, I would sit with them and have a conversation about your code, and their suggestions. Hiring someone is more than what code they produce... Can you work with this person? Are they receptive to feedback? How do they handle conflict/being challenged?