It was very obviously there as bait for people like you and it was removed as soon as they took a new job. It was never used in production in its "released" form.
I had no problem with the person's abilities to code, but for reasons like this I probably wouldn't work with them again, or hire them as a eng lead or higher.
I put the anecdote up as a real-world example of one way the GGP's github reference can be faked.
You would have to dig really hard into their knowledge of the system to catch them, which you wouldn't have time to do.
For instance, I believe the issues would show up in a benchmark.
I'd bet they could also pass a whiteboard, pair-programming or take-home test too.
That they are willing to lie about it and pass off other's work as their own isn't something that you're going to identify in your typical code interview. Using interrogation tactics to try and weed out the frauds is going to be counter-productive, by driving off all the good candidates.
But I'm not sure, I've never interviewed this person.
Ask questions about the code:
- why did you write this in this way
- explain how this works
- if you needed to add X into this, how would you do it
- are there other ways to achieve what you did here, what are the pros/cons of this?
- what would you do differently if you were to re-write this?
- are there any bugs or common issues, how do you go about diagnosing and debugging them? Could you write the code differently to be more resiliant to those issues?
Anyone who wrote that code (assuming it was relatively recently) is going to be able to talk about it sensibly, and be able to dig into the code and show how certain things are done.