I get the feeling you’ve put in more thought than usual to the candidate perspective, but I feel like there’s room for more nuance here. Some of your ideas (why did you pick react, mentioning Redux could be a bad thing) imply you think the candidate is currently in a role where they’re the sole decision-maker. But clearly many of these decisions have already been made on your project. Are you really going to hire someone in to be more senior than the person/people who already made these decisions for your team? Do you want someone who will relitigate these decisions, regardless of seniority?

Also, consider that someone could have a perspective you haven’t thought of, that might be just as good or better than the one you already have in your head. My answer about lifecycle methods would be to try to simplify what the component does enough where lifecycle methods aren’t needed, and to keep requests for data out of the View layer as much as possible (how possible that is depends more on team structure IME than technology), since data requests are not the responsibility of the View.

As a candidate, I get very concerned when a team has high regard for linters (which, IMO, often enforce arbitrary, often silly, and sometimes counterproductive rules), and see tests as a “necessary evil.” Snapshots, IMO, test that components “do what they do,” which to me is hardly reassuring and certainly doesn’t help during the design phase. Most regressions in the View come from CSS changes anyway.