As an interviewer, how do I know that you wrote that code in your GitHub profile?
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.
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'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.
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.
Sprinkle in some bugs. Start with easy spelling errors and go all the way to concurrency problems.
Ask them to add a few simple features and fix any bugs they find. Bonus points if they find bugs you didn't add intentionally. Good unit tests are also a bonus.
Give them a couple days or something. Don't count off if they don't get everything done. It's better to do a few things correctly that fix everything with hacks.
Invite them to email questions/suggestions to the hiring team. This person might be on your team so it's nice to find out early if they have good ideas or they hound you with stack overflow questions all day.
I've never had this kind of interview but it sounds nice to me. It's more realistic to real daily work. You can cheat by having someone else do the work but that's always a possibility.
Whiteboardimg a solution to n=np or building full applications is crazy and not realistic. Most interviews do that yet most work is fixing bugs and adding mundane features. Why can't interviews focus on the actual skills needed?
What’s your threat model here? People making up elaborate lies about code they’ve written?
Likely people making up elaborate lies about code they didn't write. It's trivial to push code of which you are not the author.
Why would I leave a stable well paying job for a job that basically says they don't trust me enough to not fire me in two weeks?
Manipulating one or more git repos to claim it as yours then ensuring your lie is not uncovered by googling would be technically challenging enough that those who could do probably don't need to.
Without looking at the commit history, given enough time this is a challenge. I often don't recognize code I wrote myself 6 months ago.