The Psychology of Finding the Imposter

We are terrible lie detectors — and that is the interesting part

Here is a number worth sitting with. Across 206 studies and more than 24,000 people, the average accuracy of judging whether someone is lying or telling the truth is about 54% — barely above the 50% you would get from a coin flip (Bond & DePaulo, 2006). Worse, confidence and accuracy are nearly unrelated: the people most sure they can spot a liar usually cannot.

So when players in a social deduction game reliably catch the saboteur, something other than raw lie-detection is happening. Understanding what that something is changes how you play Devception — and how you read a suspicious pull request at work.

Why our instincts fail

Most folk beliefs about lying are wrong. We watch for broken eye contact, fidgeting, and a nervous tone — but those are cues to anxiety, not deception. A calm liar sails through; an anxious but honest person looks guilty. We are not reading lies. We are reading nerves, and nerves are spread across honest and dishonest people alike.

This is exactly why Devception is a better detection environment than a face-to-face game of Mafia. The deception happens through code and behavior, not facial expressions. You are not guessing from a webcam. You are looking at an audit trail: who edited what, when, and what happened next.

The bias that gets good players killed

The single most dangerous mistake in deduction is confirmation bias — once you suspect someone, you start noticing every detail that fits and discounting everything that does not (Nickerson, 1998). You lock onto a suspect early, then unconsciously build a case against them while a quieter imposter operates freely.

The counter-move is a habit, not a talent: before you vote, deliberately try to disprove your own theory. Ask "what would I expect to see if this person were innocent — and do I see it?" In Devception that means checking the actual edit history instead of trusting the story in your head. It is the same discipline that separates a real root-cause investigation from "blame whoever touched it last."

Why experts see things you cannot

Experienced players develop something that looks like intuition but is really compressed experience. The classic work is Chase and Simon's study of chess players, which showed that masters do not have better raw memory — they chunk the board into meaningful patterns they have seen thousands of times (Chase & Simon, 1973). Show them a real position for five seconds and they reconstruct it almost perfectly; show them random pieces and they do no better than a beginner.

The same mechanism drives expert code review — a senior engineer "smells" a bug because they have seen that shape of mistake before — and it drives expert imposter-hunting. After enough matches you stop reasoning move by move and start recognizing whole patterns of suspicious behavior at a glance.

The tells that actually mean something

Unlike facial cues, the signals in a coding context are observable and checkable:

• Proximity to breakage. A test passed, someone edited near that code, the test failed. That timeline is hard evidence, not a vibe.
• Skill inconsistency. Someone writes clean, competent code in three places and then makes a "beginner" mistake in the one function that matters. Real skill is consistent; sabotage is selective.
• Reaction under scrutiny. When a bug surfaces, watch what a player does first: explain, deflect, or immediately accuse someone else. Pre-loaded accusations are a tell.
• Helpful noise. Imposters often over-communicate in safe areas to bank credibility for the moment they need it.

Playing the other side

Knowing how detection works also makes you a better imposter, which is half the fun. The strongest sabotage is not dramatic — it is a one-character change that looks like an honest mistake, dropped when attention is elsewhere, by someone who has spent the last five minutes being visibly useful. Good imposters do not hide from suspicion; they spend social credit they earned earlier.

A practical detection checklist

• Track who edited what, not just what changed.
• Weigh actions over words — talk is cheap, edit history is not.
• Actively argue against your current suspect before you commit a vote.
• Prefer the player with the most opportunity to cause the specific failure you observed.
• Notice mismatches between how someone communicates and how they actually code.

The takeaway

Finding the imposter is not a magic talent for reading people. It is evidence-handling under uncertainty, plus the self-awareness to fight your own biases — the exact skills that make someone good at code review, incident response, and security work. The biases you bring to a Devception match are the same ones you bring to a production outage. Practicing against them in a game is a surprisingly direct way to get better at the real thing.

References

• Bond, C. F. & DePaulo, B. M. (2006). Accuracy of Deception Judgments. Personality and Social Psychology Review.
• Nickerson, R. S. (1998). Confirmation Bias: A Ubiquitous Phenomenon in Many Guises. Review of General Psychology.
• Chase, W. G. & Simon, H. A. (1973). Perception in Chess. Cognitive Psychology.