About half the time you can’t because it’s not actually a form, and they forgot to add handler for enter.
When doing a take home exercise the candidate is desperate to figure out what you are judging on. The more you make that explicit the better your outcomes will be.
Right now your process biases for enter handler adders. Is that your intent?
When I give candidates prompts / questions / scenarios, I try to include some specific instructions, but also leave some details out. The idea is to come up with a prompt that junior developers can still work with by going head-on, but which has some open-ended nature to it, to see how people respond to things which are open-ended or even ambiguous. It's not a trick or trap; candidates are explicitly told what's up, and that I'm evaluating not only their ability to solve a problem, but to define the problem in the first place.
If you want to evaluate a candidate's ability to cut through ambiguity or manage sprawling scope, evaluate that and only that in a specific exercise. Don't just build a shoddy coding test and then rationalize it's weaknesses by saying that good candidates will succeed despite the flaws of the test. That's both disrespectful and un-rigorous.
Junior developers get near-real-time feedback from senior developers who are supervising them. Senior developers have to be able to give that feedback, have to be able to anticipate user needs, and have to be able to run long-term projects where you may have to work for days, weeks, or months before receiving critical pieces of feedback.
> If you want to evaluate a candidate's ability to cut through ambiguity or manage sprawling scope, evaluate that and only that in a specific exercise.
This is a common mistake that I see inexperienced interviewers make. Trying to throw more detailed and specific exercises at candidates is a fool's errand at best, and at worst it means that you're putting candidates through additional tests (and your acceptance rate will suffer).
The main problem with ambiguity is that it appears unexpectedly. If you give someone an ambiguous problem and say, "Tell me what is ambiguous about this problem," then you're not testing what you want to know. What you actually want to know is whether candidates can recognize ambiguous problems without being prompted to recognize them--and the reason for this is that ambiguous are extremely common in real-world scenarios.
An ambiguous problem is not a trick or a trap. It is explicitly part of the interview process, and interviewees are given guidance that the problems they are given may not be precisely defined.
> Don't just build a shoddy coding test and then rationalize it's weaknesses by saying that good candidates will succeed despite the flaws of the test.
Why do you say that the coding test is shoddy?
My observation is that a large percentage of candidates will succeed at coding tests if you give them an ambiguous prompt. In practice, they will either ask questions to resolve the ambiguity, or just pick a way to resolve the ambiguity for the purposes of the test. This matches real-world scenarios--you are going to often encounter ambiguous or incomplete problems in the real world.
If you want a precisely-specified coding problem, then go to Hacker Rank or Project Euler or something like that, or join a competitive programming team.
Have you tested this assertion with data? Because I’ve built interview pipelines several times now and the data I collected showed the exact opposite. The more specific a test was for the trait you wanted to select for the better results you’d get across all metrics, interviewers and candidates. It’s almost my defining characteristic of a good selection criteria after 2 decades of interviewing.
My personal experience is that people new to interviewing are the ones who think that making individual interviews more precise will improve the process, but my experience is that improvements to the overall interview process aren’t done by improving how good individual interviews are.
But, the format is not really the point. The point is to have a specific thing you are trying to discern from your filter and to focus your efforts on making that the only thing you are judging on.
Sometimes it makes sense to do something else instead, but if so, you should handle it in a sane way and actually do that something else. Not just suppress it.
Desktop frameworks “committed” input on enter and most often focused the next field, so you could skip them by enter enter enter. This worked correctly since FoxPro/TurboVision/Norton times. Only Ctrl-Enter would press a “default” button out of order.
But web has its own ways as usual.
Browsers have a standard, default, expected behavior. Sometimes, in rare cases, it makes sense to break that in order to do something else instead. But you shouldn't just silently break it for no reason other than to confuse the user.
So perhaps that isn’t the best litmus test? I wonder if it’s written down that should work as part of the assignment.
Breaking default browser behavior because you find it unintuitive is generally a bad idea.
Now if you’re dealing with something that isn’t really a web form—as in you’re overloading input fields for some interactive non form like behavior—then I can see it.
In my case, if the person had some well thought out reason for doing it, I might let it slide. But the vast majority of times I’ve seen it, it’s because the person doesn’t even know how to use forms. Not understanding the underlying technology at at least a very basic level is a strike against you in my book.
Again, it’s not that I disagree with most of your premise, but in fact, as the comments (not just mine) show - people have issues with submitting too early, so it can be a good decision to break that depending on context. Fewer errors. Which is why I brought up how the problem is presented to the candidate. You might be filtering out people based on something less universally accepted and understood than you think.
If you accidentally break it because you don’t understand it, that’s a strike against you in my book. If you consciously break it for a good reason and can coherently defend that reason, that’s a different story.
At least you'd have to get a sample big enough to make a statistically significant conclusion.
And the burden of proof is on you, because you are changing the default, not the other way around.
Think of any other products, they all have established default behaviours, yet it's also very easy to find someone who's never used a product before and finds it "unintuitive".
And intuitiveness is only one part of usability anyway.