When I've been involved in interviews from the interviewer side, I always try to focus on questions that don't have concrete, Googleable answers. Sure, it's goo

When I've been involved in interviews from the interviewer side, I always try to focus on questions that don't have concrete, Googleable answers. Sure, it's good to include a question or two to filter out the actual impostors—such as asking a candidate claiming extensive Java experience how to check string equality (it's astonishing how many people this filters out)—but after that sanity check, I'm more interested in your approach to problem-solving and communication. One fun thing to do as an interviewer is to play the role of a business analyst, asking for how they would implement a particular feature; then, make the requirements purposefully vague (while encouraging the interviewee to ask follow-up questions if they'd like). This is a lot closer to most real-world programming challenges than a detailed discussion of reactive programming.