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