5 ms·

I tend to be really solid on the ins and outs of what I'm working on right now, or in the last year. And on stuff older than that I have a good idea of the land

I tend to be really solid on the ins and outs of what I'm working on right now, or in the last year. And on stuff older than that I have a good idea of the landscape and the location of certain gotchas, but I find I have to Google certain things like syntax or accessible ways to do something as I go. In real life, that googling or checking the docs fits right into the flow of solving the problem. But for an interview it's better to be fresh on as much as you can, even if you haven't been "in it" recently. And it can help a lot with nerves. One or two follow-up questions should help the interviewer figure out whether the person has experience with something or just knows what it is, and as long as the candidate's not pretending to have used things they haven't used, it's hard for me to call preparation cheating.

organsnyder 9y ago
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.