But we’re struggling to get good signal. In many cases, the candidate’s code has multiple issues, though it’s often not clear whether they would be able to fix it with a bit more time or if it’s core misunderstandings about how to write good frontend.
We’ve debated making it an unlimited-time takehome, but we worry that this is disrespectful of a candidate’s time. We are sympathetic to candidates who are doing many of these interviews for different companies. We do know that there’s the option to pay candidate’s for their time - but we are still hesitant on doing a takehome for other reasons, for example it’s hard to compare an engineer who takes a full weekend to complete a takehome, versus someone who submits it within an hour.
Additionally, we find some value in the check-ins, to see the candidate’s thought process.
So far, though, we’ve had no luck with the current structure, so we’re looking to refactor it completely.
So my question for HN: how do you structure your frontend loops? What works and what doesn’t work? Any suggestions for a small startup looking to get good signal without taking too much of a candidate’s time?
As far as the coding test goes, I can say with utter certainty that its important that candidates are required to build something, even if its simple. We've had trouble in the past around this; meaning, candidates who could mainly only _read_ code and copy / paste were able to get through the filter. As soon as we introduced a code test instantly we had a baseline, where the candidates who couldn't successfully code something from scratch were filtered out, and the ones who's submissions looked crazy or didn't seem to follow best practices were immediately identifiable.
From there -- and this is key -- we used other aspects of the interview process to determine best fit, independent of actual code, and this combination has proven quite successful.
The most important thing the coding test does is filter out people who simply can't code. There are a LOT of folks like this, and in particular boot camp graduates. (There are also a lot of talented boot camp graduates, don't get me wrong, but we've consistently noted a problem with this model as applied to real-world working conditions.) Once you've determined that the candidate can code, really dig into everything else and try to surface their passion for the subject; because if there's that, then they'll be able to learn and grow.
What I suggest giving candidates is the skeleton project where they just need to implement the core features, without having to bootstrap an entire thing from scratch.
And yes, without having all the candidates take an off day for your coding test, you'll never have a fair comparison, so instead DO give them 7 days to do what you expect to be 4h task (and compensate them for that much). If they can only find up to 1h every night to focus on that, context switching will make those 1h not nearly as productive as a single, workday-like 4h slot that many can't dedicate to a single company.
3h is also not a lot if you expect to have some communication overhead like the check-ins you mention: either do it live with a candidate (but make it 2h), or do away with the check-ins.
You might be surprised, but senior engineers frequently have families, small kids, etc.
But even with all that, someone can spend 3h doing things you simply don't care about for the interview (eg I'd struggle not to have good test coverage; someone might set up code formatter or whatever), so be extra clear about what you are looking for. Though note that "senior" engineers have their strong opinions about what matters, so you need to give them an opportunity to defend their priorities in choosing what to focus on.
Finally, make sure to test one of your senior engineers who was not involved in the interview task creation: what kind of result do they produce in similar circumstances (with the benefit that they are not under interview pressure and they know your team's biases)?
Discussions around state management, js libraries (react, vue, etc...), testing strategies (storybook, etc...) should also give you some signals too on their experience.