That's more the type of question I'd hang out as a programming puzzle on the web and then encourage people who solve it (guide them to a solved screen) to apply with a link to a gist or similar. I've applied to companies before just because I like solving programming puzzles, and once you're at that point, why not?

FWIW, speaking as an SDET lead, I'll do something like that voluntarily, time allowing.

But I A) don't submit applications, I send resumes, so let's start there; and B) wouldn't do something like you describe as a formal prescreen. Before I've talked to you, you have maybe half an hour of my time if I've heard of you, maybe five minutes of my time if I haven't.

After you've convinced me I'd like to work for you, then I'd give you an hour or two on a project, interest depending. Any more than that, and you need to pay me. You'd also probably have to be on my short list of final employer candidates. I'm interviewing y'all too, you know. I'm more inclined to do homework after a successful round of interviews than beforehand, mostly because there'll probably be a job out there I'm equally interested in that doesn't require this. I do pay attention to how much of a pain in the ass a company is to apply to, and it does weigh into my decisions to accept (or even continue).

I realize this comes across maybe a touch arrogant, but it's honestly accurate. Ask yourself this: Do you want the type of developer desperate enough for a job to jump through hoops?

SDET is an extremely competitive niche for good developers, since the QA path tends to filter people out into other disciplines before they hit a good amount of SDET skill. A good SDET can afford to be choosy. This is more friction than I'd put on a process to hire for my team.