path: root/learn/humans/README.md

# Humans

Humans are complicated. It's probably a good idea to understand them.

## Bias

### Availability bias

occurs when the most readily information is used rather than what is most representative.

* solution: Consult with others different than you or more representative of your intended audience.

### Confirmation bias

is the tendency to utilize information in a way that

supports the existing viewpoint, but ignores information that could dispute or discredit.

* solution: Look for information that may challenge your views or ideas and invite the
  team to do the same.
* when you hear an opinion or suggestion that is different from your own show
  gratitude. Get curious and invite the team to learn together.
* Conflicting ideas fuel creativity.

### Conformity bias

Refers to how humans take cues for proper behaviour or acceptable ways of being
from others, rather than exercising independent judgement.

* Group think: when the team prefers consensus rather than conflict.
  * so members will agree with one another to maintain harmonious environment
  * team members may also pick up ways of being
    * physical mannerisms or patterns of speech among other things to adapt to
      meet the explicit and implicit group norms.
* solution: Champion new ideas
* encourage the group to use brainstorming techniques that allow suggestions
  to be documented before the team has the ability to talk and influence one
  another.

### Commitment bias

Occurs when groups or individuals continue down a course of action or decision
with increasingly negative feedback or outcomes without altering their course.

* our brains are trained to simplify information
* limits our ability to innovate
* solution: build a project and change management practices that integrate
  feedback throughout the lifespan of the project
* be explicit about what the goals are
* what are the measures for success
* layout accountability indicators

### Tips

* lean into gratitude, curiousity, and learning
* welcome divergent ways of thinking and being
* set clear objectives, measureable goals, and plan for feedback throughout the process with accountability indicators

### Detecting Bias

Imagine if that person was a different gender or a different race. Would we be
equally concerned i nthat moment?

Studies show minority employees are 3X more likely to leave an organization than
non-diverse employees.

The benefits of diversity must show up in the work for it to be effective.

## Communication

Read [Effective Communication](https://about.gitlab.com/company/culture/all-remote/effective-communication/)
and remember that neutral text is usually perceived as negative. Assume positive
intent when communicating.

Styles:

* Direct: Uses as few words as possible to express an idea.
* Socratic: Needs to tell a story to establish context before eventually arriving at a point.
* Empathetic: Adjusts their style based on the needs of the audience.

### Language

Prefer:

* *Allow* list over _white_ list.
* *Block* list over _black_ list.

Swearing is a mark of intelligence. Some swears do not age well so it is best to
avoid them.

Prefer:

* xxx over _cunt_.    # i donno but this term drives my partner wild.
* xxx over _retard_.  # insensitive towards kids with delayed development.
* xxx over _lame_.    # insensitive towards kids with physical disability.

### Issue/Pull Request Feedback

Ask don't tell. Ask questions and be curious.
Cut down on the back and forth by clearly stating your assumptions.
The person reading your comment cannot read your mind.
Use [conventional comments](https://conventionalcomments.org/) to guide you.
Ensure readers understand which one of your comments must be addressed and which
ones are non-blocking.

## Decisions

How do we make decisions? TODO::

## Interviews

Interviewing humans is tricky. Humans want money so sometimes they do naughty
things to get it. e.g. they lie.

Things that suck about interviewing:

* scheduling
* scoring
* tracking candidate performance
* evaluations
* choosing a candidate

### Process

The process that I use is:

1. Scheduling Request: Send an email asking the candidate to book a time with me. (https://calendly.com/c0-mokhan/30min)
1. Phone screen: (30 minutes or less)
  * this is quick call to make sure that we have company-candidate fit.
    * i.e. can we offer them what they are looking for and can they offer us what we need.
    * this is NOT a check to see if I want to have drinks with this person.
1. Take home test: I generate a private repo for each candidate.
1. PR Review: Andrew reviews PR's from candidates.
1. PR Discussion: The candidate and I review the PR together. (30 minutes)
1. Sorry: I send the candidate an email if they do not move on.

### Scheduling Request

I send candidates the following email:

```plaintext
To: <candidateemail>
Subject: Command Zero - Go Developer

Hello,

Thank you for applying for the role of Go Developer at https://cmdzero.io.

I would like to schedule an initial call with you to get to know you. Please find a time on my calendar by visiting:

* https://calendly.com/c0-mokhan/30min

Happy hacking,

mo
Software Engineer | CMD0
```

My Calendly form also requests that they provide me with their GitHub username.
I keep track of this to send them the take home test.

### Phone Screen

Before each call I create a separate text file with the following template:

```plaintext
<Candidate Name>

My name is mo khan and I am a software developer on the Command Zero Gatekeeper
team. I'm here to conduct a technical evaluation to see how we work together.

Today, I'm going to go through a list of questions to get a sense of what you
are looking for.

After this call I will send you an invitation to a repository on GitHub to
complete a small tech challenge and then I'll move you to the next round with
the CTO.

Does that make sense?

Questions:

* Who are you?
* Tell me about your first computer or computer program?
* What makes a good pull request?
* How do you like to receive feedback?
* How do you like to give critical feedback?
* What do you want out of your next position?
* Describe a relationship with a mentor that worked well for you in the past?
* How comfortable are you with Linux?
* What are you compenstation expectations?

Final thoughts:

<written within 30 minutes of ending the call>
```

The purpose of these questions is to answer a few things:

* How do you communicate? (direct, socratic, empathetic)
* Are you curious? How do you follow your curiousity?
* How will I know when you're stuck?
* Do you know what you want? How can I help you achieve what you want?
* Are you pragmatic or dogmatic?
* How much do you think you're worth?

This can be reduced down to a competency vs confidency ratio.

| Competenecy | Confidence |                |
| ----------- | ---------- | -------------- |
| Low         | Low        | No  Hire       |
| Low         | High       | Strong No Hire |
| High        | Low        | Strong Hire    |
| High        | High       | Hire           |

I give the candidate the option to continue to the next step which is a take
home test. I request that they do not spend more than two hours on this. I
let them know that this is to get a sense of how they communicate and break
down a problem. If they agree to continue then I run a script to generate a
new private repository on GitHub specifically for them. This also generates
an email with instructions for getting started.

### Take home test

Everyone gets the same take home test. At the moment I only have one example of
a take home test and it is specifically for Go developers working on an HTTP
API.

The template repo can be found [here](https://github.com/c0-interviews/api-auth)
and the script to generate a new repo can be found [here](https://github.com/c0-interviews/send).

The take home test has a tiny HTTP blob storage API written with a few tests.
Some of the tests are failing when candidate initially recieve the assignment.
The test attempts to evaluate candidates on the following:

* how do you prioritize the work to be done?
* do you take the time to understand the purpose of the API? i.e. problem domain vs technical domain.
* can you spot defects that are outside of the requested scope of work?
* do you understand technical concepts such as:
  * go programming
  * encoding/decoding
  * hashing
  * HTTP headers

The take home test is meant to give candidates enough time to explore a problem
on their own time so that we can discuss it together. Some people need more time
to process so I give it to them ahead of time so that we can be efficient with 
the time that we have together.

Once the candiate submits the pull request, they notify me.

### PR Review

This is when I ask for someone else in the company to review the code. Andrew
has been fantastic with reviewing these changes for me. Bringing in another set
of eyes is important to me to make sure that other engineers have a chance to
spot things that I cannot and also provide a different perspective to review.

We're still working on a rubrik for the code reviews to make it a little easier
to compare one candidates work with anothers.

### PR Discussion

After I receive feedback from the code review I ask the candidate to book
another 30 minute call with me via my Calendly link. When we meet I ask them to
share their screen and walk me through the pull request together.

I ask:

* Can you read the PR description to me?
  * this usually leads to discussion on text communication in a remote team.
* Can you tell me what this service does?
  * this helps me understand if they were focused on the code or product.
* Can you walk me through each commit starting from the oldest to the newest?
  * this helps me to understand how they broke down the problem and where they
    thought the most important place to start was.
* Can you explain base64 to me?
* Can you tell me if this API is able to detect duplicate blobs?
* How could we detect duplicate blobs?
* Can you explain hashing to me?
* Can you explain digital signatures?
* Can you explain JSON Web Tokens?
* Can you explain the HTTP Authorization header?

Depending on how the candidate is responding I may choose to go deeper to see
how far they can go or I may pause and try to give them feedback in their
preferred feedback style on the topic that I think they may not be able to
explain. I check to see how receptive they are to learning or receiving
critical feedback and if it aligns with the way they described they like to
receive feedback.

I try to reserve 5-10 minutes at the end for them to ask questions and I ask
them to give me feedback.

I end by letting them know that the next step is that I will collect all the
notes and data and present that to my boss to decide who moves on.

### Sorry

Some candidates do well in the phone screen, and poor in the code review.
The pr discussion is the opportunity to make up for any poor scoring in the
first two steps.

| candidate | phone screen | code review | code discussion | level |
| --------- | ------------ | ----------- | --------------- | ----- |
| A A       | Hire         | Hire        | Hire            | int   |
| G L       | Hire         | No Hire     | No Hire         | jr    |
| K J       | Hire         | No Hire     | No Hire         | jr    |
| L W       | Hire         | No Hire     | No Hire         | jr    |
| S L       | Hire         | Hire        |                 | jr    |
| K P       | Hire         |             |                 |       |


```
Hi <Candidate name>,

I checked in with the team today and we have decided to go in another direction. We wont be able to offer you this role at this time.

I appreciate the time that you took to interview with me and I hope that you are able to find a new position.

Thank you,

mo
```