game theory of a culture fit problem
As a game theory enjoyer, I often model human interactions in matrices. The process of modeling is quite enjoyable in the same way as programmers enjoy refactoring their own codebases - it's the essence of reduction after all.
Modeling a toxic culture or work environment is useful in a lot of ways, for example:
- provide measurable answer to the "culture fit" problem during hiring
- discover a person's level of williness on problem solving
the culture fit problem
In order to get the data from a person or a crowd of people, I would need to initiate a game. This isn't a normal game, it's more like a game theory type game, where I offer simple rules, and people begins the game with my rules in mind.
For this year, I have interviewed approximately 30 software engineer candidates for my company. My job as a engineer is to see if a candidate's skillsets match the company's hiring requirements. However, my company was small so there was no one else to check the "culture fit" aspect of a candidate.
Having interviewed a few less-than-ideal candidates for now, I think it's time to draft a general solution to tackle the culture fit question.
To initiate a game, I will need to establish some rules. My rules are often fairly simple, candidate can only answer with answer on the left or answer on the right. In mathematics, it can be written into a mutually exclusive set as:
A = {lfs, rhs}
Then I will randomly select a relatively playful question amongst software engineers, for example:
- do you prefer indentation with spaces or indent with tabs?
- do you prefer a regular text editor or vim when you lead a software project?
Format is as followed: "do you prefer apple vs orange"?
Once candidate has made a choice, a game is established:
| choice | lfs | rhs |
|---|---|---|
| lfs | (a, c) | (a, d) |
| rhs | (b, c) | (b, d) |
The rows represent the payoffs (a & b) from candidate and the column represents payoffs from myself (c & d), hypothetically.
When a candidate answer the question, for example, that generics is a preferred way of writing abstracted functions, then I will choose my answer to move the conversation forward. Note that I have the freedom to choose whichever side I want, depending on the how defensive the candidate becomes later:
then my game table will be updated with concrete payoffs:
| choice | lfs | rhs |
|---|---|---|
| lfs | (1, 0) | (1, 1) |
| rhs | (0, 0) | (0, 1) |
As shown in the example, the candidate prefers spaces than tabs, where I prefers tabs over spaces for indentation. And I will play such role that I pretend to the less informed engineer on my choice of action.
As the conversation goes along, I will ask following questions such as why prefer one way over the other to see how passionate a candidate is with such topics.
Next step is to reveal my payoffs to create a standoff situation because my payoffs clearly present the opposite side of what the candidate prefers.
Next I will start prompting a more concrete counter arguments such as:
- generics are unoptimized by the Swift compiler, it often relies on runtime for type inference, etc.
By prompting counter argument in this way, it invites candidate to fight back a little.
The goal of this exercise is to reach an outcome in a repeated game scenario. This outcome should skew towards in the middle than a definitive win or loss of each side.
That mean I should have a few more questions ready to collect behavioral data from the candidate.
Back in real life
In real life, it's normal to have candidates answering these type of questions in a neutral way. Some companies even don't reveal its own payoffs during interviews.
I have ran into a few candidates who have strong opinions on my apple vs. orange game, that forced the total payoffs skewed far towards the candidates' preference rather than the company's preference. And since it's a repeated game play, candidates can become irritated too. A few candidate will breakout from the rules and prevent me from asking questions by using a sidetrack method such as, "I don't understand the purpose of these questions" or "if you prefer performance very much, then why choose Swift as the language, rewrite the project, etc."
Sidetracking a conversation is very common behaviour from a lot of passionate developers. They often weigh their opinions higher over the concern of community (with many other contributors). So sidetracking conversations can easily pick apart details without contexts and strike a neutral or wining side of a heated argument in favour of the candidate over the hiring company.