Ask HN: What makes a good senior frontend coding interview?

[tazmin]

My startup is hiring a senior frontend developer, and we’re trying to improve our frontend coding loop. Our current loop is React-based, we give them a view of what their page should look like, test that they can design some semi-complex state to make the page function correctly. We give them 3 hours to solve it, with checkins each hour for them to ask questions and show their progress. It’s a relatively simple app to build, and we let them choose their component library.

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?

[sibeliuss]

I'd suggest requesting that the candidate limits the time they spend on it to three hours, but give them a 24 hour window to submit. Some will need more, some less, however having that limit in place will constrain things sufficiently, I think. At least, that's how we do it over here.

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.

[necovek]

Looking for people "who can code" is a pretty low bar for senior candidates.

24h for a take home is equally limiting for people with actual lives, and other than speeding up your process, it won't say anything more than a 3- or 7-day take home that's supposed to take 3h.

[sibeliuss]

Yeah, this mostly applies to less than senior candidates. That said, the argument is that the code is quite a bit secondary once you dig into their work-history, references and so on. If they can code, and the other data backs things up, then its easy to see whether they would succeed in the role. But its quite easy to get false-positives around signals only to find that they can't complete a task without handholding.

[necovek]

Asking for 3h of continuous realtime coding (even if you are not watching) is anything but respectful: depending on the mood, tiredness (am I doing this after work after my kid woke me up last night?), and how recently I've built something from scratch with whatever tech stack you are using, I might take 15 mins or 6h to solve a 3h task.

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)?

[geoelkh]

Project based but on-site for like one or two hours. Something where they consume a public api and build a UI usually a list on it. Will allow you to see their dev setup, etc... This will give you by far the most signals.

Discussions around state management, js libraries (react, vue, etc...), testing strategies (storybook, etc...) should also give you some signals too on their experience.