# 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 a 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: 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 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: ``` 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 confidence 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 the candidate initially recieves 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. There are several defects in the code that they are given. This is deliberate to see if they are willing to challenge the status quo and to see how well they trust their intuition. So far most candidate leave code comments to indicate that they think something is wrong but they chose not to do anything about it. I would love to see a candidate open an issue to describe what they see wrong so that it can be tracked and followed up on later. 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. The scoring for each step is broken down to the following scores: * Strong Hire: this candidate did very well * Hire: this candidate did well. * No Hire: we should not hire this candidate * Strong No Hire: this candidate did very poorly or violated one or more of our values. Example score sheet: | candidate | phone screen | code review | code discussion | outcome | | --------- | ------------ | ----------- | --------------- | ----- | | AA | Hire | Hire | Hire | next round | | GL | Hire | No Hire | No Hire | reject | | KJ | Hire | No Hire | No Hire | reject | | LW | Hire | No Hire | No Hire | reject | | SL | Hire | Hire | | | | KP | Hire | | | | ``` Hi , 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 ```