5 ms·

>We are hoping to add someone to the team that can improve the quality of the work we do I think that's your answer... Show them your existing front-end code,

>We are hoping to add someone to the team that can improve the quality of the work we do I think that's your answer... Show them your existing front-end code, and ask them how they'd make it better. If they're experienced, then they should have some very concrete ideas. Then ask them "why" for their ideas. If they can't fully explain the "why" behind the "what" they're probably just regurgitating things they've read, but don't actually understand the tech.

m3h 4y ago
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.
- wspeirs 4y ago
  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?
- johncoltrane 4y ago
  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.

m3h 4y ago

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.

wspeirs 4y ago
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?
johncoltrane 4y ago
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.